# 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\*
```

## Aktueller Implementierungsstand

Die nachfolgend beschriebene Path-Policy ist im NTFS-Provider inzwischen implementiert.

### 1. Materialisierung und Traversierung sind getrennt

In `GetChildDataAreasAsync()` wird pro gefundenem Pfad heute getrennt entschieden:

- darf der Pfad als DataArea geliefert werden
- darf unterhalb des Pfads weiter traversiert werden

Das ist wichtig fuer Include-Regeln. Ein Zwischenpfad darf fuer die Traversierung erlaubt sein, auch wenn erst ein tiefer liegendes Zielobjekt tatsaechlich auf der Whitelist steht.

### 2. Matching ist klassifizierungsunabhaengig

Die Path-Policy arbeitet fuer:

- `ServerRoot`
- `ClassicShare`
- `DfsNamespaceRoot`
- `DfsLink`
- `Folder`

mit derselben Matching-Logik.

Die Klassifikation bleibt fuer die fachliche Verarbeitung der DataArea relevant, nicht mehr fuer Blacklist-/Whitelist-Matching.

### 3. Relative und absolute Pfade werden parallel ausgewertet

Jeder klassifizierte Pfad wird gegen mehrere Kandidaten gematcht:

- relativer Pfad unterhalb von `RootPath`
- normalisierter absoluter UNC-Pfad

Dadurch koennen Regeln sowohl knapp relativ als auch explizit absolut formuliert werden.

### 4. Include-Regeln duerfen Traversierungs-Vorpfade freischalten

Wenn `NtfsIncludePaths` gesetzt ist, darf ein Pfad auch dann traversiert werden, wenn er selbst noch nicht final matcht, aber zu einem spaeter passenden Zielpfad fuehren kann.

Beispiel:

```text
NtfsIncludePaths=Abteilung\IT\*
```

Dann darf `Abteilung` fuer die Traversierung erhalten bleiben, damit `Abteilung\IT\TeamA` ueberhaupt erreicht werden kann.

### 5. `LoadDataArea()` respektiert die Policy

Direktes Laden eines Pfads ueber `LoadDataArea()` wird ebenfalls durch die Path-Policy eingeschraenkt.

Ausnahme:

- der konfigurierte `RootPath` selbst bleibt ladbar

Damit kann die Filterung nicht einfach durch direktes Laden einer UID umgangen werden.

### 6. Permission-Management bleibt fachlich auf Folder beschraenkt

`IsPermissionManagedFolderPath()` verwendet dieselbe generische Path-Policy, bleibt aber weiterhin nur fuer als `Folder` klassifizierte Pfade zulaessig.

Die Path-Policy ist also klassifizierungsunabhaengig, das Berechtigungs-Handling selbst aber bewusst nicht.

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

Das entspricht dem aktuell implementierten Verhalten.

## Beispiele

### 1. Einzelnen Teilbaum ausschliessen

Konfiguration:

```text
NtfsExcludePaths=Abteilung\Alt\*
```

Wirkung:

- `Abteilung\Alt` und alles darunter wird nicht mehr als DataArea geliefert
- unterhalb von `Abteilung\Alt` wird auch nicht weiter traversiert
- andere Teilbaeume bleiben unveraendert sichtbar

### 2. Bestimmte Ordnernamen ueberall ausschliessen

Konfiguration:

```text
NtfsExcludePaths=*\Temp;*\Archiv
```

Wirkung:

- jeder Pfad, dessen letzter oder einer spaeteren Segmente `Temp` oder `Archiv` entspricht, wird ausgeschlossen
- das ist praktisch fuer technische oder historische Unterordner, die in vielen Shares gleich benannt sind

### 3. Nur einen Fachbereich sichtbar lassen

Konfiguration:

```text
NtfsIncludePaths=Fachbereiche\HR\*
```

Wirkung:

- nur Pfade unterhalb von `Fachbereiche\HR` werden als DataAreas geliefert
- notwendige Zwischenpfade wie `Fachbereiche` duerfen fuer die Traversierung erhalten bleiben
- alle anderen Teilbaeume unterhalb von `RootPath` fallen aus der Ergebnismenge

### 4. Whitelist und Blacklist kombinieren

Konfiguration:

```text
NtfsIncludePaths=Fachbereiche\IT\*
NtfsExcludePaths=Fachbereiche\IT\Test;Fachbereiche\IT\Alt\*
```

Wirkung:

- grundsaetzlich ist nur `Fachbereiche\IT` relevant
- innerhalb dieses Bereichs werden `Test` und der komplette Teilbaum `Alt` wieder ausgeschlossen
- Exclude gewinnt also auch innerhalb eines eingeschraenkten Include-Bereichs

### 5. Absoluten UNC-Pfad fuer DFS-Link verwenden

Konfiguration:

```text
NtfsIncludePaths=\\server\dfs\namespace\link\Produktion\*
```

Wirkung:

- die Regel greift auch dann, wenn der Root ueber DFS klassifiziert wird
- benoetigte Vorpfade wie `\\server\dfs`, `\\server\dfs\namespace` und `\\server\dfs\namespace\link` duerfen fuer die Traversierung erhalten bleiben
- dadurch kann ein bestimmter DFS-Zweig sehr gezielt freigegeben werden

### 6. Nur bestimmte Shares unter einem Server-Root zulassen

Konfiguration:

```text
NtfsIncludePaths=ShareA\*;ShareB\*
```

Voraussetzung:

- `RootPath` zeigt auf einen Server-Root wie `\\fileserver`

Wirkung:

- nur Kinder unterhalb von `ShareA` und `ShareB` werden sichtbar
- andere Shares des Servers werden nicht materialisiert und nicht weiter traversiert

### 7. Direktes Laden eines ausgeschlossenen Pfads

Konfiguration:

```text
NtfsExcludePaths=Abteilung\Alt\*
```

Wirkung:

- ein direkter `LoadDataArea()` auf einen Pfad unterhalb von `Abteilung\Alt` liefert kein Objekt mehr
- der konfigurierte `RootPath` selbst bleibt davon ausgenommen und kann weiterhin geladen werden

## Technische Einhaengepunkte

### 1. Provider-seitige Policy-Methoden

Im NTFS-Provider existiert dafuer inzwischen eine kleine Policy-Schicht, insbesondere:

- `GetAdditionalConfigurationValues(string key)`
- `ShouldIncludeDataArea(...)`
- `ShouldTraverseDataArea(...)`
- `MatchesPathPolicy(...)`
- `TryMatchPathPolicy(...)`
- `CanPathLeadToPattern(...)`

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 vor `BuildDataAreaAsync()` sowie vor dem rekursiven Abstieg durch die Path-Policy geprueft.

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.

### 4. Wiederverwendung fuer `LoadDataArea()`

Auch `LoadDataArea()` verwendet die Path-Policy inzwischen, damit gefilterte Pfade nicht per Direktzugriff wieder sichtbar werden.

## Offene Abgrenzung

Bewusst weiterhin nicht umgesetzt:

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

Diese Themen koennen spaeter folgen, sind fuer den aktuellen Nutzen aber 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 `ShouldTraverseDataArea(...)` erweitern.
4. Debug-Logging fuer Skip-Faelle einfuehren.
5. Dieselbe Policy in `IsPermissionManagedFolderPath()` und `LoadDataArea()` wiederverwenden.

Diese Punkte sind im aktuellen Implementierungsstand umgesetzt.

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