LIAM/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md

LIAM WF GetDataAreas - Auffaelligkeiten und moegliche Fixes (initial)

Ziel des Dokuments

Dieses Dokument betrachtet ausschliesslich den Stand initial (f563d78417c8183ac0934beaa11d0f258b7537bf).

Es bewertet die Rueckfrage, warum WF Get DataAreas in einer betroffenen Situation nicht mehr hunderte Datenbereiche, sondern nur noch sehr wenige Eintraege, beispielsweise 3, zurueckliefern kann.

Ausdruecklich nicht im Fokus stehen hier:

• geaenderte MaxDepth
• geaenderte Naming-Conventions
• spaetere Aenderungen im aktuellen Hauptstand

Im Fokus stehen stattdessen nur moegliche Ursachen, die bereits im initial-Stand zu so einem Verhalten fuehren konnten:

• geaenderte Ordnerstruktur
• geaenderte Rechte auf Shares oder Ordnern
• geaenderte ACL-Situation
• geaenderte AD-Erreichbarkeit oder AD-Berechtigungen
• geaenderte DFS-Erreichbarkeit
• Logging-Luecken und stille Teilergebnisse

Kurzfazit

Im initial-Stand ist das geschilderte Verhalten grundsaetzlich moeglich.

Die plausibelsten Ursachen fuer frueher viele, jetzt nur noch wenige sind im Altstand:

• geaenderte sichtbare Ordnerstruktur unterhalb des konfigurierten RootPath
• geaenderte Leserechte auf Teilbaeumen des Dateisystems
• Probleme beim rekursiven Traversieren, die im Code als Teilergebnis statt als klarer Fehler enden
• Probleme bei der Erreichbarkeit des Root-Pfads selbst, insbesondere bei UNC-/DFS-Pfaden

Reine AD-Probleme sind im initial-Stand fuer genau das Muster es kommen noch 3 zurueck deutlich weniger plausibel.

Wenn AD im initial-Stand wirklich nicht funktioniert, fuehrt das eher zu einem Fehlschlag des Logons und damit zu null oder zu einem kompletten Fehlerbild, nicht zu einer kleinen aber formal erfolgreichen Teilmenge.

Wichtig ist auch: Der initial-Stand verwendet fuer GetDataAreas noch keine explizite DFS-Klassifikation und keine Share-Enumeration. DFS-Probleme koennen also nur indirekt ueber den UNC-Pfad und dessen Dateisystemerreichbarkeit wirken, nicht ueber die spaetere Root-/DFS-Logik des heutigen Stands.

Gepruefter Umfang

Fuer diese Einschaetzung wurden im initial-Stand insbesondere diese Dateien betrachtet:

• LiamWorkflowActivities/C4IT.LIAM.WorkflowActivities.cs
• LiamWorkflowActivities/C4IT.LIAM.WorkflowactivityBase.cs
• LiamNtfs/C4IT.LIAM.Ntfs.cs
• LiamNtfs/cNtfsBase.cs
• LiamNtfs/cActiveDirectoryBase.cs
• LiamNtfs/C4IT_IAM_SET/cNetworkConnection.cs

Workflow-Verhalten im initial-Stand

Workflow-seitig ist der initial-Stand sehr duenn.

Die damalige Methode getDataAreasFromProvider(Guid ProviderConfigClassID) ruft den Provider direkt mit ProviderEntry.Provider.getDataAreasAsync(ProviderEntry.Provider.MaxDepth) auf und behandelt null oder Count <= 0 pauschal als No data areas found.

Das bedeutet:

• Es gibt keine Unterscheidung zwischen technischem Fehler, Teilergebnis und wirklich leerem Bestand.
• Es gibt keine strukturierte Fehlerdiagnose fuer die Discovery.
• Es wird nicht protokolliert, wie viele Ordner theoretisch erreichbar gewesen waeren oder wo die Traversierung abgebrochen ist.

Damit ist bereits auf Workflow-Ebene erklaert, warum im Log oft nur wenig Aussagekraeftiges sichtbar ist.

Discovery-Logik im initial-Stand

Die eigentliche Discovery sitzt in cLiamProviderNtfs.getDataAreasAsync(int Depth = -1).

Die Logik ist im initial-Stand im Kern:

1. Lizenz pruefen
2. LogonAsync() ausfuehren
3. RootPath auf Leerwert pruefen
4. Root-Typ ueber die Anzahl der UNC-Segmente herleiten
5. ntfsBase.RequestFoldersListAsync(this.RootPath, Depth) aufrufen
6. alle zurueckgelieferten Ordner in DataAreas uebernehmen

Entscheidend ist:

• Es gibt im initial-Stand keine explizite DFS-Metadatenpruefung.
• Es gibt keine Share-Enumeration fuer den Root.
• Es wird direkt versucht, unterhalb des konfigurierten RootPath Dateisystemordner zu enumerieren.

Dadurch reagieren Ergebniszahl und Ergebnisqualitaet im initial-Stand primaer auf Dateisystemsichtbarkeit und Traversierungsrechte.

Priorisierte Auffaelligkeiten im initial-Stand

1. Hoch: Zugriffsprobleme in der Ordnerrekursion werden als Teilergebnis zurueckgegeben

Das kritischste Verhalten fuer das geschilderte Fehlerbild steckt in cNtfsBase.privRequestFoldersListAsync(DirectoryInfo rootPath, int depth, cNtfsResultFolder parent = null).

Wenn waehrend rootPath.GetDirectories() oder in tieferen Rekursionsstufen ein Fehler auftritt, landet der Code in einem allgemeinen catch und gibt einfach die bis dahin gesammelte Liste folders zurueck.

Das bedeutet fachlich:

• Ein Zugriff auf den Root kann funktionieren.
• Die Traversierung kann auf tieferen Ebenen an einzelnen Ordnern scheitern.
• Statt eines klaren Fehlers wird aber nur die bis dahin gefundene Teilmenge zurueckgegeben.

Genau dieses Verhalten passt sehr gut zu:

• frueher hunderte
• jetzt noch 3
• im Log sehe ich nichts

Wenn sich zwischenzeitlich Leserechte oder effektive Traversierungsrechte auf Teilbaeumen geaendert haben, kann der initial-Stand damit sehr gut nur noch wenige erreichbare Ordner zurueckliefern.

Das ist im initial-Stand keine theoretische Ecke, sondern ein reales stilles Fehlerbild.

Abgleich zum aktuellen Stand

Status: Nicht gefixt, weiterhin offen.

Die kritische Rekursionsstelle in cNtfsBase.cs#L143 ist im aktuellen Stand weiterhin vorhanden. Das innere catch in cNtfsBase.cs#L174 liefert nach wie vor nur die bis dahin gefundenen Ordner zurueck.

Der aktuelle NTFS-Provider hat zwar die Root- und Pfadklassifikation stark geaendert, verwendet fuer Folder-Kinder aber weiterhin RequestFoldersListAsync(...), siehe C4IT.LIAM.Ntfs.cs#L389. Damit bleibt das alte Problem der stillen Teilergebnisse erhalten.

Offenes ToDo:

• Traversierungsfehler pro Pfad explizit loggen
• Teilergebnis fachlich kennzeichnen statt still als Erfolg weiterzugeben
• im Workflow/API zwischen vollstaendig, partial und failed unterscheiden

2. Hoch: Aenderungen an der Ordnerstruktur wirken im initial-Stand direkt auf die Rueckgabemenge

Da der initial-Stand keine Root-Klassifikation ueber DFS-/Share-Metadaten macht, sondern schlicht rekursiv unterhalb von RootPath liest, haengt die Rueckgabemenge unmittelbar von der sichtbaren Ordnerstruktur ab.

Wenn beispielsweise:

• Unterordner entfernt wurden
• Verzeichnisstrukturen verschoben wurden
• Junctions oder Weiterleitungen anders wirken
• der konfigurierte Root heute auf einen kleineren Teilbaum zeigt

dann sinkt die Anzahl der gefundenen DataAreas direkt.

Im initial-Stand gibt es keine zusaetzliche semantische Schicht, die das noch abfedert oder klarer diagnostiziert.

Abgleich zum aktuellen Stand

Status: Nicht gefixt, aber fachlich veraendert.

Auch im aktuellen Stand wirkt sich die sichtbare Struktur weiterhin direkt auf die Rueckgabemenge aus. Allerdings passiert das nicht mehr nur ueber reine Ordnerrekursion, sondern ueber die neue Pfadklassifikation in C4IT.LIAM.Ntfs.cs#L285 und die Kindermittlung in C4IT.LIAM.Ntfs.cs#L363.

Das alte Finding ist damit nicht obsolet, sondern der Mechanismus ist heute breiter:

• Ordnerstruktur unterhalb eines Folder-/Share-Roots
• sichtbare Shares unterhalb eines Server-Roots
• sichtbare DFS-Objekte unterhalb eines DFS-Roots

Offenes ToDo:

• fachlich klar definieren, welche Root-Typen fuer WF GetDataAreas unterstuetzt und erwartet sind
• die ermittelte Root-Klassifikation und Kinderanzahl pro Call explizit loggen

3. Hoch: Der Root selbst muss erreichbar sein, sonst scheitert der gesamte Call

Vor dem eigentlichen Lesen fuehrt der Provider LogonAsync() aus.

Darin werden sowohl ntfsBase.LogonAsync(LI) als auch activeDirectoryBase.LogonAsync(LI) aufgerufen.

Das bedeutet:

• Der technische Benutzer muss den UNC-Root grundsaetzlich erreichen.
• Der AD-Login muss ebenfalls gelingen.

Wenn bereits der UNC-Zugriff auf RootPath scheitert, kommt es eher zu einem harten Fehlerbild.

Fuer das Muster nur noch 3 ist deshalb weniger der komplette Ausfall des Root-Zugriffs interessant, sondern eher der Fall:

• Root erreichbar
• einige Unterordner oder Teilbaeume nicht mehr sauber lesbar

Genau dann greift wieder das stille Teilergebnis aus der Rekursion.

Abgleich zum aktuellen Stand

Status: Nicht gefixt, weiterhin offen.

Die Kopplung von NTFS- und AD-Logon besteht weiterhin. Der aktuelle Provider verwendet noch immer await ntfsBase.LogonAsync(LI) && await activeDirectoryBase.LogonAsync(LI), siehe C4IT.LIAM.Ntfs.cs#L126 und C4IT.LIAM.Ntfs.cs#L140.

Fuer den aktuellen Stand gilt zusaetzlich: der Root selbst kann heute noch an mehr Infrastrukturhaengigkeiten gekoppelt sein als im initial-Stand, etwa an Share-Enumeration oder DFS-Metadaten.

Offenes ToDo:

• NTFS-Discovery fachlich von AD-Zusatzauflosung entkoppeln
• Root-Erreichbarkeit, AD-Login und spaetere Zusatzdatenaufloesung getrennt diagnostizieren

4. Mittel-Hoch: DFS-Probleme koennen im initial-Stand indirekt wirken

Im initial-Stand wird DFS fuer GetDataAreas nicht explizit ausgewertet.

Es gibt dort:

• keine DFS-Namespace-Klassifikation
• keine DFS-Link-Erkennung
• keine Nutzung von NetDfsGetInfo() im Discovery-Pfad

Das ist wichtig, weil dadurch spaetere Ursachen aus dem aktuellen Stand hier gerade nicht gelten.

Trotzdem kann DFS im initial-Stand indirekt relevant sein, wenn RootPath ein DFS-Pfad ist.

Dann wirken DFS-Probleme nicht ueber Metadatenklassifikation, sondern ueber die schlichte Tatsache, dass DirectoryInfo(rootPath).GetDirectories() auf diesem UNC-Pfad heute vielleicht nur noch teilweise oder gar nicht mehr funktioniert.

Moegliche Folgen:

• DFS-Ziel aktuell nicht sauber erreichbar
• Name oder Ziel nicht mehr korrekt aufloesbar
• technische Session landet auf anderem oder reduziertem Ziel
• Traversierung liefert nur eine kleine Teilmenge

Damit ist DFS im initial-Stand als indirekter Infrastrukturhebel durchaus plausibel, aber nicht ueber denselben Mechanismus wie im heutigen Stand.

Abgleich zum aktuellen Stand

Status: Nicht gefixt, sondern fachlich verlagert und erweitert.

Dieses Finding gilt 1:1 nur fuer initial. Im aktuellen Stand ist DFS nicht mehr nur indirekt relevant, sondern expliziter Teil der Discovery-Logik. Die DFS-Klassifikation laeuft ueber C4IT.LIAM.Ntfs.cs#L309, C4IT.LIAM.Ntfs.cs#L431 und cNetworkConnection.cs#L104.

Das bedeutet:

• Der konkrete initial-Mechanismus gilt nicht mehr unveraendert.
• Operativ ist DFS heute aber eher noch wichtiger als frueher.
• DFS-Fehler koennen im aktuellen Stand die Root-Klassifikation und damit die DataArea-Anzahl direkt beeinflussen.

Offenes ToDo:

• DFS-Aufloesungsfehler mit Rueckgabecode und betroffenem Pfad loggen
• im Diagnosepfad sichtbar machen, ob ein Pfad als DfsNamespaceRoot, DfsLink, ClassicShare, ServerRoot oder Folder klassifiziert wurde

5. Mittel: AD-Probleme erklaeren eher harte Fehler als kleine Treffermengen

Der initial-Stand koppelt NTFS- und AD-Logon eng zusammen.

Wenn activeDirectoryBase.LogonAsync(LI) scheitert, wird das gesamte LogonAsync() des Providers false, und getDataAreasAsync() gibt null zurueck.

Das spricht gegen AD als primaere Ursache fuer eine kleine, aber noch erfolgreiche Trefferliste.

Reine AD-Erreichbarkeitsprobleme passen im initial-Stand eher zu:

• kompletter Fehler
• keine DataAreas
• harter Ausfall beim Providerzugriff

Teilprobleme in AD koennen spaeter fuer Zusatzinformationen relevant sein, aber nicht besonders gut fuer nur noch 3 DataAreas.

Abgleich zum aktuellen Stand

Status: Im Kern weiterhin zutreffend, nicht grundsaetzlich gefixt.

Auch im aktuellen Stand spricht die gekoppelte Logon-Logik eher dafuer, dass echte AD-Logon-Probleme zu einem harten Fehler fuehren und nicht zu einer kleinen erfolgreichen Restliste. Die Kopplung ist weiterhin vorhanden, siehe C4IT.LIAM.Ntfs.cs#L140.

Verbessert wurde immerhin die Workflow-Rueckgabe: die neuere Runtime liefert bei null-Resultaten strukturierte Fehlercodes statt nur einer pauschalen No data areas found-Meldung, siehe LiamWorkflowRuntime.cs#L78.

Offenes ToDo:

• AD-Fehler weiterhin von reiner NTFS-Discovery entkoppeln
• bei Discovery-Calls sauber zwischen Logon failed, Traversal partial und No items found trennen

6. Mittel: ACL-/Gruppenaufloesung beeinflusst eher Zusatzdaten als die Anzahl

Die ACL-Leselogik sitzt in cActiveDirectoryBase.GetAccessControlList(string path).

Wenn dort auf einem Ordner die ACL nicht gelesen werden kann, wird null geliefert.

In der weiteren Verarbeitung fuehrt das eher dazu, dass zu einer bereits gefundenen DataArea Gruppeninformationen oder Owner-/Read-/Write-Zuordnungen fehlen.

Das reduziert im initial-Stand typischerweise nicht die Anzahl der gefundenen DataAreas selbst.

Darum gilt fuer die Fragestellung:

• geaenderte ACLs koennen die Zahl der DataAreas reduzieren, wenn sie die Ordner-Traversierung blockieren
• geaenderte ACLs erklaeren die reduzierte Zahl eher nicht, wenn nur die spaetere Permission-Group-Aufloesung betroffen ist

Abgleich zum aktuellen Stand

Status: Im Wesentlichen weiterhin zutreffend.

Auch im aktuellen Stand werden DataAreas zuerst gebaut und die Permission-Groups danach aufgeloest, siehe C4IT.LIAM.Ntfs.cs#L225. Die ACL-Leselogik in cActiveDirectoryBase.cs#L88 verhaelt sich weiterhin so, dass bei ACL-Lesefehlern eher Zusatzinformationen fehlen als ganze DataAreas verschwinden.

Der primaere Discovery-Effekt bleibt also auch heute:

• ACL-/Rechteprobleme waehrend der Ordner-Traversierung koennen die Anzahl reduzieren
• spaetere ACL-/Gruppenmapping-Probleme reduzieren meist nicht die Anzahl

Offenes ToDo:

• ACL-Lesefehler pro DataArea als Diagnosehinweis sichtbar machen
• Discovery und Permission-Mapping im Ergebnis klarer trennen

7. Mittel: Depth = 0 ist im initial-Stand fachlich fehlerhaft

Im initial-Stand liefert RequestFoldersListAsync(string rootPath, int depth) bei depth == 0 null.

Dadurch wird spaeter im Provider DAL == null als Fehler interpretiert und das bereits erzeugte Root-Objekt geht verloren.

Das ist ein echter Bug im Altstand.

Fuer die vorliegende Rueckfrage ist er aber nur dann relevant, wenn die betroffene Konfiguration wirklich MaxDepth = 0 verwendet haette.

Da Konfigurationsaenderungen hier bewusst ausgeschlossen werden sollen, ist dieser Punkt eher nachrangig, aber als Code-Auffaelligkeit im initial-Stand trotzdem wichtig.

Abgleich zum aktuellen Stand

Status: Gefixt.

Im aktuellen Stand wird das Root-Objekt zuerst erzeugt und bei Depth == 0 direkt zurueckgegeben, siehe C4IT.LIAM.Ntfs.cs#L171 bis C4IT.LIAM.Ntfs.cs#L180.

Das alte initial-Problem, dass das Root-Objekt bei Depth = 0 verloren geht, besteht damit im aktuellen Stand nicht mehr.

Bewertung der konkret genannten Umweltfaktoren fuer initial

Aenderungen an der Ordnerstruktur

Sehr plausibel.

Im initial-Stand wird direkt rekursiv unterhalb von RootPath gelesen. Wenn sich die effektive Struktur des Teilbaums geaendert hat, aendert sich die Anzahl der DataAreas unmittelbar.

Aenderungen an der Rechtesituation auf Ordnern oder Teilbaeumen

Sehr plausibel.

Das ist sogar einer der staerksten Kandidaten, weil die Rekursion bei Fehlern nicht klar scheitert, sondern mit Teilergebnissen weiterarbeitet.

Wenn der technische Benutzer bestimmte Unterordner nicht mehr listen kann, koennen ganze Teilbaeume verschwinden, ohne dass das Ergebnis als Fehler gekennzeichnet wird.

Aenderungen an ACLs

Teilweise plausibel.

Wenn ACL-Aenderungen die Ordner-Traversierung selbst beeinflussen, dann ja, sehr plausibel.

Wenn ACL-Aenderungen nur die spaetere Permission-Group-Aufloesung betreffen, dann eher nicht als Erklaerung fuer nur noch 3.

Aenderungen an AD-Rechten oder AD-Erreichbarkeit

Eher als Primaerursache unplausibel fuer dieses konkrete Muster.

Im initial-Stand fuehren ernsthafte AD-Probleme eher zum kompletten Logon-Fehler als zu einer kleinen Restliste.

Aenderungen an DFS-Erreichbarkeit

Plausibel, aber indirekt.

Im initial-Stand wirkt DFS nur ueber den UNC-Pfad und dessen praktische Erreichbarkeit. Wenn ein DFS-Pfad nicht mehr stabil oder nicht mehr gleich aufgeloest wird, kann das Lesen des Dateisystembaums reduziert oder unvollstaendig werden.

Warum man im initial-Log wenig sieht

Der initial-Stand hat mehrere Diagnoseprobleme gleichzeitig:

• Workflow-seitig gibt es nur pauschale Aussagen wie No data areas found
• in der Ordnerrekursion gibt es ein stilles catch ohne strukturierte Diagnose
• es gibt keine Statistik ueber erkannte, verworfene oder fehlgeschlagene Unterbaeume
• es gibt keine Kennzeichnung von Teilergebnissen

Dadurch kann ein fachlich stark reduziertes Ergebnis technisch wie ein normaler erfolgreicher Call aussehen.

Moegliche Fixes fuer den initial-Stand

1. Rekursive Traversierung darf Fehler nicht still in Teilergebnisse umwandeln

Empfohlene Aenderung:

• Das innere catch in privRequestFoldersListAsync() sollte nicht kommentarlos folders zurueckgeben.
• Stattdessen muss mindestens geloggt werden, an welchem Pfad die Traversierung abgebrochen ist.
• Besser waere ein Ergebnisobjekt, das Success, PartialResult und FailedPaths sauber trennt.

Nutzen:

• Berechtigungs- oder Infrastrukturfehler auf Teilbaeumen werden endlich sichtbar.
• Der Unterschied zwischen wirklich nur 3 vorhanden und nur 3 erreichbar wird nachvollziehbar.

2. Teilergebnisse im Workflow explizit kennzeichnen

Empfohlene Aenderung:

• Workflow-seitig nicht nur null oder Count <= 0 behandeln.
• Discovery-Ergebnis um Diagnosedaten erweitern, etwa:
  • IsPartial
  • FailedPathCount
  • LastTraversalError

Nutzen:

• Die Workflow-Schicht bekommt eine belastbare Grundlage fuer Support und Betrieb.

3. RootPath und Traversierungsstatistik mitloggen

Empfohlene Aenderung:

Pro Call mindestens loggen:

• RootPath
• Depth
• Anzahl direkt gefundener Ordner
• Anzahl rekursiv gefundener Ordner
• Anzahl abgebrochener Teilbaeume

Nutzen:

• Schon ein einzelner Logauszug reicht spaeter fuer eine deutlich bessere Einordnung.

4. AD-Login fuer reine Discovery vom ACL-/Gruppenmapping entkoppeln

Empfohlene Aenderung:

• Fuer die reine Ordnerdiscovery sollte die NTFS-Erreichbarkeit ausschlaggebend sein.
• AD-Fehler sollten die spaetere Zusatzdatenaufloesung beeintraechtigen koennen, aber nicht zwingend die gesamte Discovery blockieren.

Nutzen:

• Reine AD-Stoerungen fuehren nicht mehr automatisch dazu, dass Discovery unnoetig komplett scheitert.
• Die Ursachenanalyse wird klarer getrennt.

5. Diagnosemodus fuer den Dateibaum einfuehren

Empfohlene Aenderung:

• Optionaler Diagnosemodus, der je Traversierungsebene protokolliert:
  • welcher Pfad gelesen wurde
  • wie viele Unterordner gefunden wurden
  • an welchem Pfad ein Fehler auftrat

Nutzen:

• Gerade fuer sporadische Infrastrukturprobleme ist das deutlich hilfreicher als das bisherige allgemeine Fehlerbild.

Praktische Pruefungen fuer den betroffenen initial-Fall

Wenn der Fehler im initial-Stand analysiert werden soll, sind diese Pruefungen am wahrscheinlichsten zielfuehrend:

1. Den exakten RootPath der betroffenen Konfiguration pruefen.
2. Mit dem technischen Benutzer denselben UNC-Pfad ausserhalb des Workflows rekursiv lesen.
3. Pruefen, ob auf tieferen Teilbaeumen Leserechte oder Traversierungsrechte geaendert wurden.
4. Falls der RootPath ein DFS-Pfad ist, pruefen, ob dieser im betroffenen Zeitraum noch auf dasselbe Ziel und mit derselben Erreichbarkeit aufgeloest wurde.
5. AD-Probleme nur dann priorisieren, wenn es Indizien fuer generelle Logon-Fehler oder komplett fehlgeschlagene Providerinitialisierung gibt.

Schlussbewertung

Nur fuer den Stand initial betrachtet, sind die wahrscheinlichsten Ursachen fuer statt hunderten nur noch 3 DataAreas:

• geaenderte sichtbare Ordnerstruktur
• geaenderte Leserechte auf Unterordnern oder Teilbaeumen
• indirekte DFS-/UNC-Erreichbarkeitsprobleme auf dem verwendeten Root-Pfad

Deutlich weniger wahrscheinlich als primaere Ursache sind:

• reine AD-Rechteprobleme
• reine ACL-/Gruppenmapping-Probleme nach erfolgreicher Discovery

Die wichtigste technische Auffaelligkeit im initial-Stand ist, dass Fehler in der Ordnerrekursion still zu Teilergebnissen werden koennen. Genau das kann das beobachtete Verhalten sehr gut erklaeren, ohne dass im Log ein klarer Fehler sichtbar wird.