Add initial WF GetDataAreas findings
This commit is contained in:
Meik
@@ -0,0 +1,354 @@
|
||||
# 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.
|
||||
|
||||
### 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.
|
||||
|
||||
### 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.
|
||||
|
||||
### 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.
|
||||
|
||||
### 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`.
|
||||
|
||||
### 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
|
||||
|
||||
### 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.
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user