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