# 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 NTFS-Pfade mitzugeben.

Die Policy soll klassifizierungsunabhaengig arbeiten und damit fuer Shares, DFS-Links, DFS-Namespaces und Folder dieselbe Matching-Logik verwenden.

## 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 Pfad:

- darf als DataArea materialisiert werden
- darf weiter traversiert werden

Ein ausgeschlossener Pfad soll weder als DataArea geliefert noch weiter traversiert werden.

## Vorgeschlagene Konfigurationsschluessel

### Aktueller Stand

- `NtfsExcludePaths`
- `NtfsIncludePaths`

Beispiel:

```text
NtfsExcludePaths=Archiv;*\Temp;Abteilung\Alt;\\server\share\legacy\*
NtfsIncludePaths=Fachbereiche\*;Shares\Produktion\*;\\server\dfs\namespace\link\*
```

## Matching-Regeln

Empfohlene Semantik:

- Trennzeichen fuer Mehrfachwerte: `;`
- Auswertung case-insensitive
- Leerzeichen an Eintraegen vor dem Match trimmen
- 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:

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)`
- `MatchesPathPolicy(...)`
- `TryMatchPathPolicy(...)`

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. Wiederverwendung fuer Permission-Management

`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.

## Bewusste Abgrenzung fuer Schritt 1

Nicht Teil des ersten Schritts:

- Umbau von `cNtfsBase` auf generische Filter-Callbacks
- freie Regex-Konfiguration in `AdditionalConfiguration`
- unterschiedliche Regeln je Klassifikationstyp

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 'NtfsExcludePaths=IT\_disabled'
```

Das ist wichtig, damit fehlende DataAreas spaeter im Betrieb nachvollziehbar bleiben.

## Empfohlener Umsetzungsplan

1. Listenparser fuer `AdditionalConfiguration` im NTFS-Provider einfuehren.
2. Pfadnormalisierung und Matching fuer relative sowie absolute Pfade kapseln.
3. `GetChildDataAreasAsync()` um `ShouldTraversePath()` erweitern.
4. Debug-Logging fuer Skip-Faelle einfuehren.
5. Dieselbe Policy in `IsPermissionManagedFolderPath()` und `LoadDataArea()` wiederverwenden.

## Kurzfazit

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.