Add NTFS blacklist whitelist concept

Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md

@@ -0,0 +1,148 @@
+# LIAM NTFS AdditionalConfiguration Blacklist / Whitelist - Technischer Entwurf
+
+## Ziel
+
+Dieses Dokument beschreibt einen kleinen technischen Entwurf, um dem NTFS-Provider ueber `AdditionalConfiguration` eine Blacklist und spaeter optional auch eine Whitelist fuer Ordner mitzugeben.
+
+Im ersten Schritt soll damit die Enumeration von Unterordnern fuer `getDataAreasAsync()` gezielt eingeschraenkt werden, ohne bestehende Konfigurationen zu brechen.
+
+## Ausgangslage
+
+Der NTFS-Provider verfuegt heute bereits ueber `AdditionalConfiguration`, nutzt diese im NTFS-Code aber im Wesentlichen nur fuer boolesche Feature-Flags.
+
+Die Ermittlung der DataAreas erfolgt aktuell rekursiv ueber:
+
+- Root-Aufbau in `getDataAreasAsync()`
+- Kind-Ermittlung in `GetChildDataAreasAsync()`
+- Dateisystem-Enumeration je Ebene ueber `ntfsBase.RequestFoldersListAsync(parentPath, 1)`
+
+Der bestehende Filter `ShouldIncludeDataArea()` wirkt nur auf den `DisplayName` und basiert auf `DataAreaRegEx`. Das ist fuer gezielte Ordnerausschluesse fachlich und technisch zu grob.
+
+## Zielbild
+
+Die neue Logik soll eine explizite Pfad-Policy fuer den NTFS-Provider einfuehren.
+
+Diese Policy entscheidet fuer jeden gefundenen Unterordner:
+
+- darf als DataArea materialisiert werden
+- darf weiter traversiert werden
+
+Fuer Schritt 1 reicht es, wenn ein ausgeschlossener Ordner weder als DataArea geliefert noch weiter traversiert wird.
+
+## Vorgeschlagene Konfigurationsschluessel
+
+### Minimal fuer Schritt 1
+
+- `NtfsExcludeFolderNames`
+- `NtfsExcludeRelativePaths`
+
+Beispiel:
+
+```text
+NtfsExcludeFolderNames=Temp;Archiv;System Volume Information
+NtfsExcludeRelativePaths=Abteilung\Alt;IT\_disabled
+```
+
+### Erweiterbar fuer Schritt 2
+
+- `NtfsIncludeFolderNames`
+- `NtfsIncludeRelativePaths`
+
+Beispiel:
+
+```text
+NtfsIncludeRelativePaths=Fachbereiche\*;Shares\Produktion\*
+```
+
+## Matching-Regeln
+
+Empfohlene Semantik:
+
+- Trennzeichen fuer Mehrfachwerte: `;`
+- Auswertung case-insensitive
+- Leerzeichen an Eintraegen vor dem Match trimmen
+- Pfade relativ zu `RootPath` vergleichen
+- Interne Normalisierung auf konsistente UNC-/Directory-Notation
+- Zunaechst nur einfache Wildcards `*` unterstuetzen, keine freien Regex-Ausdruecke
+
+Empfohlene Prioritaet:
+
+1. Wenn keine Include-Regel gesetzt ist, sind alle Pfade grundsaetzlich erlaubt.
+2. Wenn Include-Regeln gesetzt sind, sind nur passende Pfade erlaubt.
+3. Exclude-Regeln werden danach angewendet und gewinnen bei Kollision.
+
+Damit bleibt das Verhalten ohne neue Konfiguration unveraendert, und spaetere Whitelist-Faelle sind sauber modellierbar.
+
+## Technische Einhaengepunkte
+
+### 1. Provider-seitige Policy-Methoden
+
+Im NTFS-Provider sollte eine kleine Policy-Schicht entstehen, zum Beispiel:
+
+- `GetAdditionalConfigurationValues(string key)`
+- `ShouldTraversePath(string fullPath)`
+- `MatchesFolderNamePolicy(string folderName)`
+- `MatchesRelativePathPolicy(string fullPath)`
+
+Die Methode `IsAdditionalConfigurationEnabled()` bleibt fuer boolesche Flags bestehen und wird durch Listen-/String-Helfer ergaenzt.
+
+### 2. Anwendung in der DataArea-Traversierung
+
+Der erste und wichtigste Einhaengepunkt ist `GetChildDataAreasAsync()`.
+
+Dort wird heute jede gefundene Ebene verarbeitet und bei `depth > 1` weiter traversiert. Genau dort sollte vor `BuildDataAreaAsync()` und vor dem rekursiven Abstieg entschieden werden, ob ein Pfad ausgeschlossen ist.
+
+Vorteil:
+
+- geringe Eingriffstiefe
+- kein Umbau der allgemeinen NTFS-Basis erforderlich
+- fachliche Wirkung genau dort, wo DataAreas erzeugt werden
+
+### 3. Spaetere Wiederverwendung fuer Permission-Management
+
+Aktuell erlaubt `IsPermissionManagedFolderPath()` jeden als `Folder` klassifizierten Pfad.
+
+Wenn ausgeschlossene Ordner spaeter auch nicht mehr fuer Berechtigungs-Provisionierung oder Traverse-Gruppen bearbeitet werden sollen, sollte dieselbe Policy dort wiederverwendet werden.
+
+Damit wird vermieden, dass ein Ordner zwar nicht mehr als DataArea sichtbar ist, aber weiterhin im Permission-Flow auftaucht.
+
+## Bewusste Abgrenzung fuer Schritt 1
+
+Nicht Teil des ersten Schritts:
+
+- Umbau von `cNtfsBase` auf generische Filter-Callbacks
+- freie Regex-Konfiguration in `AdditionalConfiguration`
+- unterschiedliche Regeln fuer Shares, DFS-Links und Folder
+- Policy-Auswertung fuer `LoadDataArea()` ausserhalb des normalen Traversal-Falls
+
+Diese Themen koennen spaeter folgen, sind aber fuer den initialen Nutzen nicht noetig.
+
+## Logging
+
+Fuer ausgeschlossene Pfade sollte auf `Debug` geloggt werden:
+
+- welcher Pfad verworfen wurde
+- welche Regel gegriffen hat
+- ob der Pfad nur nicht materialisiert oder auch nicht traversiert wurde
+
+Beispiel:
+
+```text
+Skip NTFS path '\\server\share\IT\_disabled' due to AdditionalConfiguration rule 'NtfsExcludeRelativePaths'
+```
+
+Das ist wichtig, damit fehlende DataAreas spaeter im Betrieb nachvollziehbar bleiben.
+
+## Empfohlener Umsetzungsplan
+
+1. Listenparser fuer `AdditionalConfiguration` im NTFS-Provider einfuehren.
+2. Pfadnormalisierung und relatives Matching gegen `RootPath` kapseln.
+3. `GetChildDataAreasAsync()` um `ShouldTraversePath()` erweitern.
+4. Debug-Logging fuer Skip-Faelle einfuehren.
+5. Optional in einem zweiten Schritt dieselbe Policy in `IsPermissionManagedFolderPath()` wiederverwenden.
+
+## Kurzfazit
+
+Fuer den ersten Schritt ist eine blacklist-basierte Pfad-Policy im NTFS-Provider der pragmatischste Weg.
+
+Sie ist klein genug fuer eine risikoarme Implementierung, passt in die vorhandene `AdditionalConfiguration`-Architektur und laesst sich spaeter ohne Bruch zu einer echten Include-/Exclude-Policy ausbauen.