Meik/LIAM
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cd133c67e1281d9194841f83583ac255c50311ed
LIAM/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes.md
Meik ece7fd8e7c Document WF GetDataAreas NTFS findings
2026-03-16 13:47:59 +01:00

20 KiB
Raw Blame History

LIAM WF GetDataAreas - Auffaelligkeiten und moegliche Fixes

Ziel des Dokuments

Dieses Dokument fasst die Untersuchung zum Verhalten von WF Get DataAreas zusammen, wenn in einer betroffenen NTFS-/DFS-Situation ploetzlich nur noch sehr wenige Datenbereiche, beispielsweise 3, statt vorher hunderten Eintraegen zurueckgeliefert werden.

Der Fokus liegt bewusst nicht auf geaenderter MaxDepth oder geaenderten Naming-Conventions. Diese Faktoren wurden fuer die Bewertung zunaechst ausgeklammert. Stattdessen betrachtet dieses Dokument vor allem:

  • geaenderte Ordnerstruktur
  • geaenderte DFS- oder Share-Struktur
  • geaenderte Rechte auf Shares, Ordnern oder ACLs
  • geaenderte Erreichbarkeit von DFS-, Fileserver- oder AD-Systemen
  • Logging-Luecken und stille Fehlerbilder
  • moegliche fachliche und technische Fixes

Kurzfazit

Das auffaelligste technische Risiko liegt im aktuellen NTFS-Provider und nicht in der Workflow-Huelle selbst.

Im Vergleich zum initial-Stand wurde das Verhalten des NTFS-Providers relevant geaendert. Der Provider klassifiziert den RootPath heute zuerst semantisch und traversiert danach unterschiedlich fuer Server-Roots, klassische Shares, DFS-Roots, DFS-Links und Folder.

Dadurch koennen sich Ergebnisanzahlen aendern, obwohl WF Get DataAreas selbst unveraendert aufgerufen wird.

Fuer das geschilderte Fehlerbild sind insbesondere drei Ursachen realistisch:

  • Der konfigurierte oder effektiv aufgeloeste Root wird heute anders klassifiziert als frueher, beispielsweise als Server-Root oder DFS-Root.
  • Die DFS-/Share-Ermittlung liefert aufgrund von Umgebungsaenderungen oder Erreichbarkeitsproblemen weniger Kinder.
  • Die rekursive Ordnerermittlung laeuft bei Zugriffsproblemen nur noch teilweise durch und gibt still Teilergebnisse zurueck.

AD-Probleme koennen ebenfalls eine Rolle spielen, sind fuer genau das Muster es kommen noch 3 Eintraege zurueck aber eher nachrangig. Totale AD-Ausfaelle fuehren im aktuellen Code eher zu einem harten Fehlschlag oder null, nicht zu einer kleinen aber formal gueltigen Trefferliste.

Umfang der Pruefung

Geprueft wurden insbesondere diese Komponenten:

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

Zum Vergleich wurde auch der initial-Stand betrachtet, insbesondere das damalige Verhalten in LiamNtfs/C4IT.LIAM.Ntfs.cs.

Ausgangsbeobachtung

Workflow-seitig wird fuer den Provideraufbau im Wesentlichen nur die Provider-Konfiguration aus Matrix42 gelesen und danach provider.getDataAreasAsync(provider.MaxDepth) aufgerufen.

Relevante Stellen:

Die Workflow-Schicht selbst loggt an dieser Stelle weder die Root-Klassifikation noch die Anzahl der gefundenen DataAreas noch Unterschiede zwischen Vollergebnis und Teilergebnis. Das erklaert bereits, warum im Workflow-Log wenig bis nichts Auffaelliges sichtbar sein kann.

Relevante Verhaltensaenderung gegenueber initial

Alter Stand

Im initial-Stand war die Logik im NTFS-Provider deutlich einfacher.

Der Provider hat:

  • aus der UNC-Pfadtiefe abgeleitet, ob Root eher Share oder Folder ist
  • danach direkt RequestFoldersListAsync(this.RootPath, Depth) aufgerufen
  • die gelieferten Folder stumpf in DataAreas uebernommen

Es gab also keine explizite DFS-/Share-/Server-Root-Klassifikation.

Aktueller Stand

Heute wird der Root-Pfad zuerst klassifiziert und danach je nach Typ unterschiedlich behandelt.

Relevante Stellen:

Dazu passen die Commits:

  • d28cfe0 Classify NTFS and DFS data areas
  • f14d4ec Classify NTFS paths via DFS metadata
  • 9cfd266 Support NTFS server roots

Diese Aenderungen sind fachlich sinnvoll, aber sie fuehren dazu, dass identische oder aehnliche Konfigurationen auf Veraenderungen in DFS-, Share- oder Zugriffsmetadaten viel staerker reagieren als frueher.

Priorisierte Auffaelligkeiten

1. Hoch: DFS- oder Share-Struktur kann die Anzahl der DataAreas direkt veraendern

Der aktuelle Provider behandelt einen Server-Root anders als einen klassischen Share und anders als einen DFS-Root.

Bei einem Server-Root werden die Kinder nicht ueber Dateisystemordner gelesen, sondern ueber veroefentlichte Shares des Servers.

Relevante Stellen:

Bei einem DFS-Pfad wird zunaechst versucht, ueber DFS-Metadaten den Pfad semantisch einzuordnen.

Relevante Stellen:

Fachliche Folge:

  • Wenn sich DFS-Links, Namespace-Struktur oder veröffentlichte Shares geaendert haben, aendert sich die Ergebnisliste unmittelbar.
  • Wenn heute beispielsweise nur noch zwei direkte Share-/Link-Kinder sichtbar sind, ist ein Ergebnis wie 3 plausibel: ein Root-Objekt plus zwei Kinder.

2. Hoch: Zugriffsprobleme auf Unterordner fuehren zu stillen Teilergebnissen

Die rekursive Ordnerermittlung in cNtfsBase hat ein besonders kritisches Verhalten.

Wenn waehrend der Rekursion eine Exception auftritt, wird im inneren catch einfach die bis dahin gesammelte Teilmenge zurueckgegeben. Diese Situation wird an genau der entscheidenden Stelle nicht geloggt.

Relevante Stellen:

Das ist fuer das geschilderte Fehlerbild besonders relevant.

Wenn sich Berechtigungen auf Teilbaeumen geaendert haben, kann die Traversierung bestimmte Aeste nicht mehr vollstaendig aufloesen. Der Call endet dann nicht zwangslaeufig mit einem Fehler, sondern mit einem kleineren, formal gueltigen Resultset.

Genau das passt zu Aussagen wie:

  • frueher hunderte Eintraege
  • jetzt noch wenige Eintraege
  • im Log nichts Eindeutiges sichtbar

3. Hoch: Share-Ermittlung kann still auf wenige oder keine Treffer kollabieren

Die Share-Ermittlung erfolgt ueber NetShareEnum.

Relevante Stelle:

Wenn NetShareEnum einen Fehlercode liefert, wird daraus kein normaler Exception-Pfad, sondern ein Dummy-Eintrag der Form ERROR=<code> erzeugt.

Relevante Stelle:

Im Provider werden solche Eintraege spaeter als nicht sichtbare Disk-Shares weggefiltert.

Relevante Stelle:

Fachliche Folge:

  • Fehler in der Share-Ermittlung koennen zu einer leeren oder sehr kleinen Kindliste fuehren.
  • Das muss nicht als harter Fehler im Workflow auftauchen.
  • Eine geaenderte Rechte- oder Netzsituation auf dem Fileserver kann also direkt die Anzahl der DataAreas beeinflussen.

4. Mittel-Hoch: DFS-Metadatenprobleme koennen still zu anderer Klassifikation fuehren

Die Methode TryGetDfsEntryPath() liefert bei ausbleibender DFS-Aufloesung schlicht false.

Relevante Stellen:

Dabei wird ein normaler Fehlercode des Windows-APIs nicht als fachlicher Fehler an den Provideraufrufer weitergereicht. Der Provider interpretiert das schlicht als kein DFS-Treffer und faellt auf andere Heuristiken zurueck.

Moegliche Folge:

  • derselbe UNC-Pfad wird je nach DFS-Verfuegbarkeit unterschiedlich klassifiziert
  • dadurch aendert sich die Kinderermittlung
  • dadurch aendert sich die Anzahl der DataAreas

5. Mittel: AD-Ausfaelle sind eher kein gutes Match fuer nur noch 3

Der NTFS-Provider-Login verlangt sowohl NTFS- als auch AD-Login.

Relevante Stelle:

Wenn AD komplett nicht erreichbar ist oder die AD-Anmeldung scheitert, passt das eher zu:

  • kompletter Fehler
  • null
  • explizitem Logon-Fehler

und weniger zu einem kleinen aber erfolgreichen Ergebnis.

Das bedeutet nicht, dass AD nie beteiligt ist. AD kann in Folgeschritten relevant sein, insbesondere bei ACL- und Gruppenaufloesung. Aber fuer die reine Anzahl der gefundenen DataAreas ist AD nach aktuellem Code eher ein Sekundaerfaktor.

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

Bei der Aufloesung von Permission-Groups werden ACLs gelesen und SID-zu-Gruppe-Aufloesungen versucht.

Relevante Stellen:

Wenn das Lesen der ACL fehlschlaegt, wird in GetAccessControlList() null zurueckgegeben und ResolvePermissionGroupsAsync() beendet sich einfach.

Fachliche Folge:

  • Die DataArea bleibt im Ergebnis erhalten.
  • Es fehlen eher Permission-Gruppen-Zuordnungen.
  • Das reduziert typischerweise nicht die Anzahl der DataAreas.

Deshalb ist eine reine ACL-/AD-Gruppenproblematik fuer nur noch 3 eher weniger passend als ein Struktur- oder Traversierungsproblem.

Warum im Log oft nichts zu sehen ist

Das aktuelle Logging ist fuer diese Problemklasse zu schwach.

Workflow-Ebene

LiamWorkflowRuntime uebergibt den Call und verarbeitet nur Erfolgs- oder Fehlerstatus.

Relevante Stelle:

Es werden nicht geloggt:

  • klassifizierter Root-Typ
  • Anzahl der direkten Kinder
  • Anzahl der rekursiv gefundenen Folder
  • Unterschied zwischen Vollergebnis und Teilergebnis
  • DFS-/Share-spezifische API-Rueckgaben

NTFS-Ebene

Die problematischsten Stellen geben Teilergebnisse zurueck oder filtern Fehler indirekt weg.

Beispiele:

Das erklaert, warum ein auffaellig kleiner Rueckgabewert nicht automatisch einen klaren Fehler im Log erzeugt.

Bewertung der vom Fachbereich genannten Umweltfaktoren

Aenderungen an der Ordnerstruktur

Sehr plausibel.

Wenn sich die Struktur unterhalb des Roots oder die sichtbaren direkten Kinder geaendert haben, aendert sich die Zahl der gefundenen DataAreas direkt.

Besonders plausibel ist das, wenn der Root heute semantisch eher auf einen Server-Root, DFS-Root oder einen hoeheren Einstiegspunkt zeigt als frueher.

Aenderungen an DFS-Systemen

Sehr plausibel.

Wenn DFS-Metadaten anders aufgeloest werden, Links entfernt wurden, Namespace-Targets geaendert wurden oder die DFS-Aufloesung zeitweise nicht funktioniert, kann die aktuelle Klassifikation und damit das Ergebnis sofort anders aussehen.

Aenderungen an Share-Berechtigungen oder Share-Sichtbarkeit

Sehr plausibel.

Die Share-Ermittlung haengt von der Serverantwort auf NetShareEnum ab. Wenn der ausfuehrende Kontext dort heute weniger oder keine vernuenftig auswertbaren Eintraege erhaelt, schrumpft die Kindliste.

Aenderungen an NTFS-ACLs auf Ordnern

Plausibel.

Wenn die rekursive Traversierung auf bestimmten Unterordnern scheitert, koennen Teilbaeume still aus dem Ergebnis herausfallen. Das ist eines der staerksten erklaerenden Muster fuer frueher viele, heute wenige.

Aenderungen an AD-Rechten oder allgemeiner AD-Erreichbarkeit

Nur eingeschraenkt plausibel.

Totale AD-Ausfaelle wuerden eher zu einem harten Fehlerbild fuehren. Teilprobleme bei SID-/Gruppenaufloesung erklaeren eher fehlende Zusatzinformationen als eine drastisch reduzierte Anzahl von DataAreas.

Moegliche Fixes

1. Traversierungsfehler nicht mehr still als Teilerfolg behandeln

Empfohlene Aenderung:

  • Das innere catch in cNtfsBase.privRequestFoldersListAsync() darf nicht nur die bisherige Teilmenge zurueckgeben.
  • Stattdessen sollte ein strukturierter Fehlerzustand gesetzt werden, beispielsweise TraversalHadErrors, LastTraversalException oder ein Provider-Error-Code.
  • Optional kann es zwei Modi geben: strict fuer harten Fehler und best-effort fuer Teilergebnis mit expliziter Warnung.

Ziel:

Der Aufrufer muss unterscheiden koennen zwischen:

  • vollstaendigem Ergebnis
  • Teilergebnis wegen Zugriffsfehlern
  • komplettem Fehler

2. Share-Ermittlungsfehler explizit loggen und propagieren

Empfohlene Aenderung:

  • NetShareEnum-Fehler nicht ueber ERROR=<code> maskieren.
  • Stattdessen Fehlercode und Servername explizit loggen.
  • Provider-seitig muss ein leerer Share-Satz von einem Share-Ermittlungsfehler unterscheidbar sein.

Ziel:

Eine reduzierte Kindliste wegen echter Share-Abfragefehler soll im Log klar von es existieren wirklich nur 3 Shares unterscheidbar sein.

3. DFS-Aufloesungsfehler als Diagnoseinformation sichtbar machen

Empfohlene Aenderung:

  • Rueckgabecode aus NetDfsGetInfo loggen, wenn kein DFS-Treffer aufgeloest werden kann.
  • Im Provider zusaetzlich protokollieren, ob ein Pfad als DfsNamespaceRoot, DfsLink, ClassicShare, ServerRoot oder Folder klassifiziert wurde.

Ziel:

Wenn sich dieselbe Konfiguration in unterschiedlichen Umgebungszustand unterschiedlich verhaelt, muss diese Abzweigung sichtbar sein.

4. Ergebnisstatistik pro Call loggen

Empfohlene Aenderung:

Mindestens folgende Werte einmal pro getDataAreasAsync() loggen:

  • RootPath
  • klassifizierter Root-Typ
  • Depth
  • Anzahl direkter Kinder
  • Anzahl rekursiv gefundener Kinder
  • Anzahl verworfener Elemente wegen Fehlern
  • Anzahl verworfener Elemente wegen Filterung

Ziel:

Ein einzelner Workflow-Lauf soll spaeter rekonstruierbar sein, ohne tief in Debugging oder Fremdsysteme zu muessen.

5. Optionalen Diagnosemodus fuer WF GetDataAreas einfuehren

Empfohlene Aenderung:

  • Optionaler AdditionalConfiguration-Schalter wie VerboseDataAreaDiscovery.
  • Wenn aktiviert, loggt der Provider jede Traversierungsstufe und jeden Klassifikationsschritt.

Ziel:

Probleme in produktionsnahen Umgebungen koennen gezielt untersucht werden, ohne permanent sehr viel Logvolumen zu erzeugen.

6. Trennung zwischen DataArea-Findung und Permission-Group-Aufloesung schaerfen

Empfohlene Aenderung:

  • Fehler bei ACL-/Permission-Group-Aufloesung sollten fachlich getrennt von der eigentlichen DataArea-Findung behandelt werden.
  • Im Ergebnis sollte sichtbar sein, ob DataAreas korrekt gefunden wurden, aber Zusatzdaten nur teilweise aufloesbar waren.

Ziel:

AD- und ACL-Probleme sollen nicht indirekt die Ursachenanalyse fuer reine Discovery-Probleme verschleiern.

Konkrete Pruefungen fuer den betroffenen Fall

1. Exakten Root-Pfad des betroffenen Providers pruefen

Wichtig ist der genaue Wert von GCCTarget.

Zu unterscheiden ist insbesondere:

  • \\server
  • \\server\share
  • \\server\share\folder
  • \\server\namespace
  • \\server\namespace\link

Mit dem aktuellen Provider ist das fachlich nicht gleichwertig.

2. Sichtbare Shares fuer den technischen Benutzer pruefen

Pruefen, ob der ausfuehrende Kontext auf dem Zielserver noch dieselben Shares enumerieren kann wie frueher.

Wenn nicht, ist die reduzierte Anzahl der DataAreas kein Workflow-Fehler, sondern ein Discovery-Effekt im NTFS-Provider.

3. DFS-Aufloesung im betroffenen Zeitraum pruefen

Pruefen, ob das betroffene System denselben Namespace und dieselben DFS-Links noch aufloesen konnte.

Bereits sporadische DFS-Probleme koennen zu anderer Klassifikation fuehren.

4. Rekursive Leserechte auf dem Root und auf tieferen Teilbaeumen pruefen

Pruefen, ob der technische Benutzer auf Unterordnern noch GetDirectories() ausfuehren kann.

Wenn das auf einzelnen Aesten nicht mehr geht, sind stille Teilergebnisse mit deutlich weniger DataAreas sehr plausibel.

5. Ergebnis gegen einen direkten Dateisystemtest spiegeln

Wenn moeglich, sollte derselbe Benutzerkontext ausserhalb des Workflows den Root-Pfad einmal rekursiv lesen.

Wenn dort ebenfalls nur noch wenige oder nur bestimmte Teilbaeume sichtbar sind, ist die Ursache sehr wahrscheinlich ausserhalb der Workflow-Schicht zu suchen.

Empfohlene Reihenfolge fuer moegliche Umsetzungen

Kurzfristig

  • Logging fuer Root-Klassifikation und Ergebnisstatistik ergaenzen
  • Traversierungsfehler sichtbar machen
  • Share- und DFS-API-Fehler explizit loggen

Mittelfristig

  • saubere Provider-Fehlercodes fuer partial result einfuehren
  • WF-Output um Diagnosehinweise erweitern
  • Diagnosemodus fuer Discovery einbauen

Langfristig

  • strikte Trennung zwischen Discovery, ACL-Lesen und Gruppenaufloesung
  • klarer fachlicher Vertrag, ob best-effort oder strict discovery gewuenscht ist

Schlussbewertung

Wenn MaxDepth und Naming-Conventions bewusst ausgeklammert werden, sind fuer das beobachtete Verhalten am wahrscheinlichsten:

  • geaenderte DFS-/Share-Struktur
  • geaenderte Sichtbarkeit oder Erreichbarkeit von DFS-/Share-Metadaten
  • geaenderte NTFS-Leserechte auf Teilbaeumen

Weniger wahrscheinlich als primaere Ursache sind reine AD- oder ACL-Gruppenprobleme. Diese erklaeren eher fehlende Zusatzinformationen als einen Rueckgang von hunderten auf wenige DataAreas.

Die wichtigste technische Auffaelligkeit ist, dass der aktuelle Code mehrere dieser Umweltprobleme nicht als klaren Fehler meldet, sondern in Teilergebnisse oder indirekt gefilterte Trefferlisten uebersetzt. Genau deshalb kann im Log wenig sichtbar sein, obwohl sich das Resultat drastisch geaendert hat.

Reference in New Issue View Git Blame Copy Permalink