Generalize NTFS path policy

Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md

@@ -2,9 +2,9 @@
 
 ## 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.
+Dieses Dokument beschreibt einen kleinen technischen Entwurf, um dem NTFS-Provider ueber `AdditionalConfiguration` eine Blacklist und spaeter optional auch eine Whitelist fuer NTFS-Pfade mitzugeben.
 
-Im ersten Schritt soll damit die Enumeration von Unterordnern fuer `getDataAreasAsync()` gezielt eingeschraenkt werden, ohne bestehende Konfigurationen zu brechen.
+Die Policy soll klassifizierungsunabhaengig arbeiten und damit fuer Shares, DFS-Links, DFS-Namespaces und Folder dieselbe Matching-Logik verwenden.
 
 ## Ausgangslage
 
@@ -22,36 +22,25 @@ Der bestehende Filter `ShouldIncludeDataArea()` wirkt nur auf den `DisplayName`
 
 Die neue Logik soll eine explizite Pfad-Policy fuer den NTFS-Provider einfuehren.
 
-Diese Policy entscheidet fuer jeden gefundenen Unterordner:
+Diese Policy entscheidet fuer jeden gefundenen Pfad:
 
 - 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.
+Ein ausgeschlossener Pfad soll weder als DataArea geliefert noch weiter traversiert werden.
 
 ## Vorgeschlagene Konfigurationsschluessel
 
-### Minimal fuer Schritt 1
+### Aktueller Stand
 
-- `NtfsExcludeFolderNames`
-- `NtfsExcludeRelativePaths`
+- `NtfsExcludePaths`
+- `NtfsIncludePaths`
 
 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\*
+NtfsExcludePaths=Archiv;*\Temp;Abteilung\Alt;\\server\share\legacy\*
+NtfsIncludePaths=Fachbereiche\*;Shares\Produktion\*;\\server\dfs\namespace\link\*
 ```
 
 ## Matching-Regeln
@@ -61,9 +50,10 @@ Empfohlene Semantik:
 - Trennzeichen fuer Mehrfachwerte: `;`
 - Auswertung case-insensitive
 - Leerzeichen an Eintraegen vor dem Match trimmen
-- Pfade relativ zu `RootPath` vergleichen
+- Matching gegen relative Pfade unter `RootPath` und gegen normalisierte absolute UNC-Pfade
 - Interne Normalisierung auf konsistente UNC-/Directory-Notation
 - Zunaechst nur einfache Wildcards `*` unterstuetzen, keine freien Regex-Ausdruecke
+- Include-Regeln duerfen fuer die Traversierung auch uebergeordnete Pfade freischalten, wenn diese zu einem spaeter passenden Zielpfad fuehren
 
 Empfohlene Prioritaet:
 
@@ -81,8 +71,8 @@ Im NTFS-Provider sollte eine kleine Policy-Schicht entstehen, zum Beispiel:
 
 - `GetAdditionalConfigurationValues(string key)`
 - `ShouldTraversePath(string fullPath)`
-- `MatchesFolderNamePolicy(string folderName)`
-- `MatchesRelativePathPolicy(string fullPath)`
+- `MatchesPathPolicy(...)`
+- `TryMatchPathPolicy(...)`
 
 Die Methode `IsAdditionalConfigurationEnabled()` bleibt fuer boolesche Flags bestehen und wird durch Listen-/String-Helfer ergaenzt.
 
@@ -98,11 +88,9 @@ Vorteil:
 - kein Umbau der allgemeinen NTFS-Basis erforderlich
 - fachliche Wirkung genau dort, wo DataAreas erzeugt werden
 
-### 3. Spaetere Wiederverwendung fuer Permission-Management
+### 3. 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.
+`IsPermissionManagedFolderPath()` bleibt fachlich auf Folder beschraenkt, verwendet fuer Black-/Whitelist aber dieselbe generische Path-Policy.
 
 Damit wird vermieden, dass ein Ordner zwar nicht mehr als DataArea sichtbar ist, aber weiterhin im Permission-Flow auftaucht.
 
@@ -112,8 +100,7 @@ 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
+- unterschiedliche Regeln je Klassifikationstyp
 
 Diese Themen koennen spaeter folgen, sind aber fuer den initialen Nutzen nicht noetig.
 
@@ -128,7 +115,7 @@ Fuer ausgeschlossene Pfade sollte auf `Debug` geloggt werden:
 Beispiel:
 
 ```text
-Skip NTFS path '\\server\share\IT\_disabled' due to AdditionalConfiguration rule 'NtfsExcludeRelativePaths'
+Skip NTFS path '\\server\share\IT\_disabled' due to AdditionalConfiguration rule 'NtfsExcludePaths=IT\_disabled'
 ```
 
 Das ist wichtig, damit fehlende DataAreas spaeter im Betrieb nachvollziehbar bleiben.
@@ -136,13 +123,11 @@ Das ist wichtig, damit fehlende DataAreas spaeter im Betrieb nachvollziehbar ble
 ## Empfohlener Umsetzungsplan
 
 1. Listenparser fuer `AdditionalConfiguration` im NTFS-Provider einfuehren.
-2. Pfadnormalisierung und relatives Matching gegen `RootPath` kapseln.
+2. Pfadnormalisierung und Matching fuer relative sowie absolute Pfade kapseln.
 3. `GetChildDataAreasAsync()` um `ShouldTraversePath()` erweitern.
 4. Debug-Logging fuer Skip-Faelle einfuehren.
-5. Optional in einem zweiten Schritt dieselbe Policy in `IsPermissionManagedFolderPath()` wiederverwenden.
+5. Dieselbe Policy in `IsPermissionManagedFolderPath()` und `LoadDataArea()` 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.
+Die generische Path-Policy im NTFS-Provider ist klein genug fuer eine risikoarme Implementierung, passt in die vorhandene `AdditionalConfiguration`-Architektur und arbeitet ohne Sonderregeln pro Klassifikationstyp.