Add DFS metadata classification concept
This commit is contained in:
Meik
396
Sonstiges/LIAM_NTFS_DFS_Metadaten_Klassifikation_Konzept.md
Normal file
396
Sonstiges/LIAM_NTFS_DFS_Metadaten_Klassifikation_Konzept.md
Normal file
@@ -0,0 +1,396 @@
|
|||||||
|
# LIAM NTFS / DFS Metadaten-Klassifikation - konkretes Umsetzungskonzept
|
||||||
|
|
||||||
|
## Ziel
|
||||||
|
|
||||||
|
Dieses Dokument beschreibt die konkrete Zielumsetzung fuer die robuste Klassifikation von UNC-Pfaden im LIAM-NTFS-Provider.
|
||||||
|
|
||||||
|
Rahmenbedingungen:
|
||||||
|
|
||||||
|
- keine Erweiterung der bestehenden Provider-Config
|
||||||
|
- der Code darf nicht voraussetzen, auf dem DFS- oder SMB-Server selbst zu laufen
|
||||||
|
- DFS-Strukturen koennen unterschiedlich aufgebaut sein
|
||||||
|
- es muss sauber unterschieden werden zwischen:
|
||||||
|
- klassischem SMB-Share
|
||||||
|
- DFS-Namespace-Root
|
||||||
|
- DFS-Link
|
||||||
|
- echtem Folder
|
||||||
|
|
||||||
|
Die bestehende Config liefert dafuer nur den Einstiegspunkt und die Zugriffsrechte:
|
||||||
|
|
||||||
|
- `RootPath`
|
||||||
|
- `Domain`
|
||||||
|
- `Credential`
|
||||||
|
|
||||||
|
Die eigentliche Typbestimmung muss daher zur Laufzeit ueber Metadaten des adressierten UNC-Pfads erfolgen.
|
||||||
|
|
||||||
|
## Kurzfazit
|
||||||
|
|
||||||
|
Die robuste Loesung ist:
|
||||||
|
|
||||||
|
1. UNC-Pfad normalisieren
|
||||||
|
2. DFS-Metadaten fuer den Pfad und relevante Praefixe abfragen
|
||||||
|
3. wenn kein DFS-Treffer vorliegt, SMB-Share-Metadaten abfragen
|
||||||
|
4. alles unterhalb einer erkannten fachlichen Grenze als Folder behandeln
|
||||||
|
|
||||||
|
Die aktuelle Segment-Heuristik wird damit ersetzt, nicht nur verbessert.
|
||||||
|
|
||||||
|
## Fachregeln
|
||||||
|
|
||||||
|
Es gelten folgende semantische Regeln:
|
||||||
|
|
||||||
|
- `\\server\\namespace` ist ein `DfsNamespaceRoot`, wenn der Pfad als DFS-Namespace-Root aufgeloest werden kann.
|
||||||
|
- `\\server\\namespace\\link` ist ein `DfsLink`, wenn der Pfad als DFS-Link aufgeloest werden kann.
|
||||||
|
- `\\server\\share` ist ein `ClassicShare`, wenn der Share auf dem Server publiziert ist und kein DFS-Treffer vorliegt.
|
||||||
|
- jeder Pfad unterhalb eines `DfsLink` ist ein `Folder`
|
||||||
|
- jeder Pfad unterhalb eines `ClassicShare` ist ein `Folder`
|
||||||
|
- jeder Pfad unterhalb eines `DfsNamespaceRoot`, aber oberhalb eines `DfsLink`, ist nur dann `Folder`, wenn er kein DFS-Link ist und fachlich wirklich Dateisystemstruktur repraesentiert; fuer den Normalfall sind direkte Kinder eines Namespace-Roots als DFS-Links zu erwarten
|
||||||
|
|
||||||
|
## Verwendbare Laufzeit-Metadaten
|
||||||
|
|
||||||
|
### 1. DFS-Metadaten
|
||||||
|
|
||||||
|
Primaere Quelle fuer DFS:
|
||||||
|
|
||||||
|
- Win32 DFS API, bevorzugt `NetDfsGetInfo`
|
||||||
|
|
||||||
|
Damit kann fuer einen UNC-Pfad geprueft werden:
|
||||||
|
|
||||||
|
- ist der Pfad ein DFS-Objekt?
|
||||||
|
- handelt es sich um Root oder Link?
|
||||||
|
- welche Targets sind hinterlegt?
|
||||||
|
|
||||||
|
Wichtig:
|
||||||
|
|
||||||
|
- diese Abfrage funktioniert remote gegen den adressierten Namespace
|
||||||
|
- sie benoetigt keine lokale Ausfuehrung auf dem DFS-Server
|
||||||
|
- sie ist fachlich deutlich verlaesslicher als `Directory.Exists(...)`
|
||||||
|
|
||||||
|
### 2. SMB-Share-Metadaten
|
||||||
|
|
||||||
|
Primaere Quelle fuer klassische Shares:
|
||||||
|
|
||||||
|
- `NetShareEnum`
|
||||||
|
- optional ergaenzend `NetShareGetInfo`
|
||||||
|
|
||||||
|
Das ist fuer LIAM bereits teilweise vorhanden:
|
||||||
|
|
||||||
|
- `cNetworkConnection.EnumNetShares(server)`
|
||||||
|
|
||||||
|
Damit kann geprueft werden:
|
||||||
|
|
||||||
|
- ob `\\server\\share` ein echter publizierter SMB-Share ist
|
||||||
|
- welche sichtbaren Disk-Shares auf dem Host existieren
|
||||||
|
|
||||||
|
### 3. Dateisystem-Metadaten
|
||||||
|
|
||||||
|
Nur fuer Folder:
|
||||||
|
|
||||||
|
- `Directory.Exists`
|
||||||
|
- `DirectoryInfo`
|
||||||
|
|
||||||
|
Diese Daten duerfen nicht fuer die Unterscheidung zwischen DFS und Share benutzt werden, sondern nur nachdem bereits eine fachliche Grenze erkannt wurde.
|
||||||
|
|
||||||
|
## Nicht ausreichende Datenquellen
|
||||||
|
|
||||||
|
Folgende Informationen reichen fuer die Typbestimmung nicht aus:
|
||||||
|
|
||||||
|
- Anzahl der UNC-Segmente
|
||||||
|
- `RootPath` alleine
|
||||||
|
- `Directory.Exists`
|
||||||
|
- ACLs
|
||||||
|
- Naming Conventions
|
||||||
|
- Custom Tags
|
||||||
|
- Group Strategy
|
||||||
|
|
||||||
|
Diese Daten koennen ergaenzend helfen, liefern aber keine robuste Aussage ueber DFS vs. SMB.
|
||||||
|
|
||||||
|
## Zielmodell
|
||||||
|
|
||||||
|
Internes Modell:
|
||||||
|
|
||||||
|
- `ServerRoot`
|
||||||
|
- `ClassicShare`
|
||||||
|
- `DfsNamespaceRoot`
|
||||||
|
- `DfsLink`
|
||||||
|
- `Folder`
|
||||||
|
- `Unknown`
|
||||||
|
|
||||||
|
Externe LIAM-Abbildung:
|
||||||
|
|
||||||
|
- `ClassicShare` -> `NtfsShare`
|
||||||
|
- `DfsNamespaceRoot` -> `DfsNamespaceRoot`
|
||||||
|
- `DfsLink` -> `NtfsShare`
|
||||||
|
- `Folder` -> `NtfsFolder`
|
||||||
|
|
||||||
|
Damit bleibt die fachliche Aussenwirkung stabil:
|
||||||
|
|
||||||
|
- DFS-Link bleibt nach aussen ein share-aehnliches Objekt
|
||||||
|
- DFS-Namespace-Root bleibt eigenstaendig sichtbar
|
||||||
|
|
||||||
|
## Konkreter Klassifikationsalgorithmus
|
||||||
|
|
||||||
|
### Schritt 1: Normalisierung
|
||||||
|
|
||||||
|
Jeder Eingabepfad wird zuerst vereinheitlicht:
|
||||||
|
|
||||||
|
- Slash zu Backslash
|
||||||
|
- doppelte Separatoren bereinigen
|
||||||
|
- UNC-Praefix sicherstellen
|
||||||
|
- Trailing Backslash entfernen
|
||||||
|
|
||||||
|
Beispiel:
|
||||||
|
|
||||||
|
- `\\SERVER\\share\\`
|
||||||
|
- `//server/share`
|
||||||
|
|
||||||
|
werden intern zu:
|
||||||
|
|
||||||
|
- `\\server\\share`
|
||||||
|
|
||||||
|
fuer Vergleiche kann case-insensitive gearbeitet werden.
|
||||||
|
|
||||||
|
### Schritt 2: DFS zuerst pruefen
|
||||||
|
|
||||||
|
Fuer den gesamten Pfad und seine relevanten Praefixe werden DFS-Metadaten geprueft.
|
||||||
|
|
||||||
|
Beispiele:
|
||||||
|
|
||||||
|
- bei `\\server\\namespace\\link\\folder`
|
||||||
|
- pruefe `\\server\\namespace`
|
||||||
|
- pruefe `\\server\\namespace\\link`
|
||||||
|
|
||||||
|
Entscheidungsregel:
|
||||||
|
|
||||||
|
- wenn der volle Pfad ein DFS-Namespace-Root ist -> `DfsNamespaceRoot`
|
||||||
|
- wenn der volle Pfad ein DFS-Link ist -> `DfsLink`
|
||||||
|
- wenn ein Praefix ein DFS-Link ist und der Gesamtpfad darunter liegt -> `Folder`
|
||||||
|
- wenn ein Praefix ein DFS-Namespace-Root ist, aber noch kein DFS-Link erkannt wurde, wird weiter geprueft
|
||||||
|
|
||||||
|
Wichtig:
|
||||||
|
|
||||||
|
- der tiefste erkannte DFS-Link gewinnt als fachliche Grenze
|
||||||
|
- die Share-Grenze ist dann genau dieser Link-Pfad
|
||||||
|
|
||||||
|
### Schritt 3: SMB-Share pruefen
|
||||||
|
|
||||||
|
Nur wenn kein DFS-Ergebnis vorliegt:
|
||||||
|
|
||||||
|
- ermittle sichtbare Shares des Servers per `NetShareEnum`
|
||||||
|
- pruefe, ob `\\server\\share` exakt ein publizierter Share ist
|
||||||
|
|
||||||
|
Entscheidungsregel:
|
||||||
|
|
||||||
|
- wenn der volle Pfad exakt einem Share entspricht -> `ClassicShare`
|
||||||
|
- wenn ein Praefix exakt einem Share entspricht und der Gesamtpfad darunter liegt -> `Folder`
|
||||||
|
|
||||||
|
### Schritt 4: Folder nur relativ zu einer erkannten Grenze
|
||||||
|
|
||||||
|
Ein Pfad ist nur dann sicher `Folder`, wenn bereits eine fachliche Grenze erkannt wurde:
|
||||||
|
|
||||||
|
- klassischer Share
|
||||||
|
- DFS-Link
|
||||||
|
|
||||||
|
Beispiele:
|
||||||
|
|
||||||
|
- `\\server\\share\\dept` -> `Folder`, wenn `\\server\\share` ein ClassicShare ist
|
||||||
|
- `\\server\\namespace\\link\\dept` -> `Folder`, wenn `\\server\\namespace\\link` ein DfsLink ist
|
||||||
|
|
||||||
|
### Schritt 5: Unknown statt falscher Sicherheit
|
||||||
|
|
||||||
|
Wenn weder DFS noch SMB sicher bestimmt werden koennen:
|
||||||
|
|
||||||
|
- liefere intern `Unknown`
|
||||||
|
- logge die Ursache
|
||||||
|
- triff keine stille Segment-basierten Fallback-Entscheidung
|
||||||
|
|
||||||
|
## Erforderliche Runtime-Abfragen
|
||||||
|
|
||||||
|
### DFSResolver
|
||||||
|
|
||||||
|
Neue interne Hilfskomponente:
|
||||||
|
|
||||||
|
- `TryGetDfsMetadata(path, out metadata)`
|
||||||
|
|
||||||
|
Rueckgabedaten:
|
||||||
|
|
||||||
|
- `Exists`
|
||||||
|
- `IsNamespaceRoot`
|
||||||
|
- `IsLink`
|
||||||
|
- `Path`
|
||||||
|
- `EntryPath`
|
||||||
|
- `Targets`
|
||||||
|
|
||||||
|
Empfohlene Implementierung:
|
||||||
|
|
||||||
|
- P/Invoke gegen `NetDfsGetInfo`
|
||||||
|
|
||||||
|
Sinnvolle Aufrufmuster:
|
||||||
|
|
||||||
|
- pruefe `\\server\\namespace`
|
||||||
|
- pruefe `\\server\\namespace\\link`
|
||||||
|
- cache Ergebnisse je Pfad
|
||||||
|
|
||||||
|
### ShareResolver
|
||||||
|
|
||||||
|
Bestehende Hilfskomponente weiterverwenden:
|
||||||
|
|
||||||
|
- `EnumNetShares(server)`
|
||||||
|
|
||||||
|
Ergaenzung:
|
||||||
|
|
||||||
|
- optional Hilfsmethode `IsPublishedShare(server, shareName)`
|
||||||
|
- Cache je Server
|
||||||
|
|
||||||
|
## Neue zentrale Datenstruktur
|
||||||
|
|
||||||
|
Empfohlene interne Rueckgabe:
|
||||||
|
|
||||||
|
```text
|
||||||
|
PathClassification
|
||||||
|
- NormalizedPath
|
||||||
|
- Kind
|
||||||
|
- BoundaryPath
|
||||||
|
- ParentBoundaryPath
|
||||||
|
- BackingType
|
||||||
|
- ResolvedFrom
|
||||||
|
- Diagnostics
|
||||||
|
```
|
||||||
|
|
||||||
|
Dabei bedeutet:
|
||||||
|
|
||||||
|
- `BoundaryPath`: fachliche Share-Grenze
|
||||||
|
- `ParentBoundaryPath`: Parent-Objekt fuer LIAM-ParentUID
|
||||||
|
- `BackingType`: `DFS` oder `SMB`
|
||||||
|
- `ResolvedFrom`: z. B. `DfsLinkPrefix`, `SharePrefix`, `FullPathDfsRoot`
|
||||||
|
|
||||||
|
## Verhalten fuer typische Faelle
|
||||||
|
|
||||||
|
### Fall A
|
||||||
|
|
||||||
|
Pfad:
|
||||||
|
|
||||||
|
- `\\SRVWSM001.imagoverum.com\\file_shares`
|
||||||
|
|
||||||
|
Erwartung:
|
||||||
|
|
||||||
|
- wenn DFS-Metadaten Root bestaetigen -> `DfsNamespaceRoot`
|
||||||
|
|
||||||
|
### Fall B
|
||||||
|
|
||||||
|
Pfad:
|
||||||
|
|
||||||
|
- `\\SRVWSM001.imagoverum.com\\file_shares\\share2`
|
||||||
|
|
||||||
|
Erwartung:
|
||||||
|
|
||||||
|
- wenn DFS-Metadaten Link bestaetigen -> intern `DfsLink`, extern `NtfsShare`
|
||||||
|
|
||||||
|
### Fall C
|
||||||
|
|
||||||
|
Pfad:
|
||||||
|
|
||||||
|
- `\\SRVWSM001.imagoverum.com\\file_shares\\share2\\test33`
|
||||||
|
|
||||||
|
Erwartung:
|
||||||
|
|
||||||
|
- wenn `\\...\\file_shares\\share2` als DFS-Link erkannt wurde -> `Folder`
|
||||||
|
|
||||||
|
## Anpassung von `getDataAreasAsync()`
|
||||||
|
|
||||||
|
Die Enumeration darf nicht mehr nur mit `RequestFoldersListAsync(RootPath, depth)` arbeiten.
|
||||||
|
|
||||||
|
Stattdessen:
|
||||||
|
|
||||||
|
- Root zuerst klassifizieren
|
||||||
|
- Kinder je nach Root-Typ enumerieren
|
||||||
|
|
||||||
|
Regeln:
|
||||||
|
|
||||||
|
- `ClassicShare`
|
||||||
|
- Kinder per Dateisystem-Verzeichnisliste
|
||||||
|
- `DfsNamespaceRoot`
|
||||||
|
- direkte Kinder primaer ueber DFS-Namespace-Inhaltsmetadaten
|
||||||
|
- nur diese direkten Kinder sind fachlich Share-aehnliche Eintraege
|
||||||
|
- `DfsLink`
|
||||||
|
- Kinder per Dateisystem-Verzeichnisliste unterhalb des Link-Ziels bzw. unter dem UNC-Linkpfad
|
||||||
|
- `Folder`
|
||||||
|
- Kinder per Dateisystem-Verzeichnisliste
|
||||||
|
|
||||||
|
Der aktuelle Fehler entsteht gerade dadurch, dass direkte Kinder eines DFS-Namespace-Roots wie normale Ordner enumeriert und spaeter wieder als Folder behandelt werden.
|
||||||
|
|
||||||
|
## Anpassung von `LoadDataArea()`
|
||||||
|
|
||||||
|
`LoadDataArea()` muss dieselbe zentrale Klassifikation benutzen wie `getDataAreasAsync()`.
|
||||||
|
|
||||||
|
Wichtig:
|
||||||
|
|
||||||
|
- keine eigene Kurzlogik
|
||||||
|
- keine Typentscheidung ueber Segmentzahl
|
||||||
|
- gleiche `PathClassification` fuer denselben Pfad wie im Listenpfad
|
||||||
|
|
||||||
|
## Logging
|
||||||
|
|
||||||
|
Fuer Diagnosefaelle sollten folgende Logeintraege vorhanden sein:
|
||||||
|
|
||||||
|
- welcher Pfad wird klassifiziert
|
||||||
|
- welcher DFS-Check wurde ausgefuehrt
|
||||||
|
- welcher Share-Check wurde ausgefuehrt
|
||||||
|
- welcher Praefix als Boundary erkannt wurde
|
||||||
|
- warum ein Pfad `Unknown` wurde
|
||||||
|
|
||||||
|
Beispiel:
|
||||||
|
|
||||||
|
- `Path '\\server\\namespace\\link\\team' classified as Folder via DFS link boundary '\\server\\namespace\\link'`
|
||||||
|
|
||||||
|
## Fehlerverhalten
|
||||||
|
|
||||||
|
Wenn DFS-Abfragen fehlschlagen:
|
||||||
|
|
||||||
|
- Fehler loggen
|
||||||
|
- weiter mit SMB-Pruefung
|
||||||
|
|
||||||
|
Wenn SMB-Abfragen fehlschlagen:
|
||||||
|
|
||||||
|
- Fehler loggen
|
||||||
|
- nicht automatisch Folder annehmen
|
||||||
|
|
||||||
|
Wenn beides fehlschlaegt:
|
||||||
|
|
||||||
|
- `Unknown`
|
||||||
|
|
||||||
|
Damit wird falsche Typvergabe vermieden.
|
||||||
|
|
||||||
|
## Performance
|
||||||
|
|
||||||
|
Noetige Caches:
|
||||||
|
|
||||||
|
- DFS-Metadaten-Cache pro Pfad
|
||||||
|
- Share-Liste pro Server
|
||||||
|
|
||||||
|
Empfehlung:
|
||||||
|
|
||||||
|
- innerhalb eines Provider-Laufs cachen
|
||||||
|
- keine globale Langzeitpersistenz
|
||||||
|
|
||||||
|
## Konkrete Implementierungsschritte
|
||||||
|
|
||||||
|
1. neue interne Resolver-Komponente fuer DFS-Metadaten einfuehren
|
||||||
|
2. bestehende Share-Abfrage in dedizierte Share-Resolver-Methode kapseln
|
||||||
|
3. `ClassifyPath()` auf Metadaten-basierte Entscheidung umbauen
|
||||||
|
4. `getDataAreasAsync()` root-typabhaengig enumerieren
|
||||||
|
5. `LoadDataArea()` auf dieselbe Klassifikation umstellen
|
||||||
|
6. JSON-Rueckgabe unveraendert lassen:
|
||||||
|
- `DfsNamespaceRoot` als eigener `DataAreaType`
|
||||||
|
- `DfsLink` nach aussen als `NtfsShare`
|
||||||
|
- `Folder` als `NtfsFolder`
|
||||||
|
|
||||||
|
## Entscheidung
|
||||||
|
|
||||||
|
Die empfohlene Umsetzung ohne Config-Erweiterung ist:
|
||||||
|
|
||||||
|
- `RootPath` aus der vorhandenen Config nur als Einstieg verwenden
|
||||||
|
- DFS-Metadaten zur Laufzeit ueber API abfragen
|
||||||
|
- SMB-Share-Metadaten zur Laufzeit ueber `NetShareEnum` abfragen
|
||||||
|
- Folder ausschliesslich relativ zu einer erkannten fachlichen Grenze ableiten
|
||||||
|
|
||||||
|
Nur so koennen klassische Shares, DFS-Namespaces, DFS-Links und echte Folder belastbar unterschieden werden, auch wenn LIAM nicht auf dem Zielserver selbst laeuft.
|
||||||
Reference in New Issue
Block a user