diff --git a/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md b/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md index 1e42002..e42e159 100644 --- a/Sonstiges/LIAM_WF_GetDataAreas_Auffaelligkeiten_und_moegliche_Fixes (initial).md +++ b/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