# 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`](/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.

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`](/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.

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`](/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.

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`](/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.

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`](/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)`.

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`](/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`.

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`](/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

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.
