Update initial findings with head comparison

Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md

@@ -108,6 +108,20 @@ Wenn sich zwischenzeitlich Leserechte oder effektive Traversierungsrechte auf Te
 
 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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/cNtfsBase.cs#L143) ist im aktuellen Stand weiterhin vorhanden. Das innere `catch` in [`cNtfsBase.cs#L174`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/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.
@@ -123,6 +137,23 @@ 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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/C4IT.LIAM.Ntfs.cs#L285) und die Kindermittlung in [`C4IT.LIAM.Ntfs.cs#L363`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/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.
@@ -143,6 +174,19 @@ Fuer das Muster `nur noch 3` ist deshalb weniger der komplette Ausfall des Root-
 
 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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/C4IT.LIAM.Ntfs.cs#L126) und [`C4IT.LIAM.Ntfs.cs#L140`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/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.
@@ -168,6 +212,23 @@ Moegliche Folgen:
 
 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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/C4IT.LIAM.Ntfs.cs#L309), [`C4IT.LIAM.Ntfs.cs#L431`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/C4IT.LIAM.Ntfs.cs#L431) und [`cNetworkConnection.cs#L104`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/C4IT_IAM_SET/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.
@@ -184,6 +245,19 @@ Reine AD-Erreichbarkeitsprobleme passen im `initial`-Stand eher zu:
 
 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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamWorkflowActivities/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)`.
@@ -199,6 +273,22 @@ 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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/C4IT.LIAM.Ntfs.cs#L225). Die ACL-Leselogik in [`cActiveDirectoryBase.cs#L88`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/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`.
@@ -211,6 +301,14 @@ Fuer die vorliegende Rueckfrage ist er aber nur dann relevant, wenn die betroffe
 
 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`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/C4IT.LIAM.Ntfs.cs#L171) bis [`C4IT.LIAM.Ntfs.cs#L180`](/mnt/c/Workspace/C4IT%20DEV%20LIAM%20WEB%20Service_git/LiamNtfs/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