Verständnisfrage zu fdoForceFileSystem

[Guido Eisenbeis]

Es geht um den TFileOpenDialog, dem man Options mitgeben kann, z. B. fdoForceFileSystem. Dazu wird in der Hilfe und im INet geschrieben:

fdoForceFileSystem - Zurückgegebene Einträge müssen Einträge des Dateisystems sein.

Vielleicht stehe ich auf dem Schlauch, aber was sind Einträge des Dateisystems? :gruebel:

Hintergrund ist, dass es ein Dialog zum Auswählen von Ordnern ist (fdoPickFolders) und ich herausfinden will, ob die o. g. Option sinnvoll ist.

[Der schöne Günther]

Die Frage ist eher "Was sind nicht Einträge des Dateisystems"?

Das hier gibt ein Beispiel:
https://stackoverflow.com/q/47086367

(Delphis

Delphi-Quellcode:

fdoForceFileSystem

ist das Gegenstück zu Windows

Delphi-Quellcode:

FOS_FORCEFILESYSTEM

)

[Guido Eisenbeis]

Hallo Der schöne Günther. Die verlinkte Seite habe ich durchgelesen.

Zitat:

Zitat von Der schöne Günther;1454221(Delphis [DELPHI

fdoForceFileSystem[/DELPHI] ist das Gegenstück zu Windows

Delphi-Quellcode:

FOS_FORCEFILESYSTEM

)

Wenn du meintest "Delphis

Delphi-Quellcode:

fdoForceFileSystem

ist das Gegenstück die Entsprechung zu Windows

Delphi-Quellcode:

FOS_FORCEFILESYSTEM

" und ich das richtig verstehe, meint "Einträge des Dateisystems" quasi -echte- Pfade. Also im Umkehrschluss wären Nicht-Einträge-des-Dateisystems virtuelle Pfade, z. B. Bibliotheken in Win7, virtuelle LWs, Hardlinks, SUBST-Ordner, usw.

Habe ich das richtig verstanden?

[himitsu]

Hartlinks, Subst usw. sind auch "echte" Pfade.

Einfach gesagt ist es alles was dem Schema C:\irgendwas\... entspricht (inkl. dem, was via UNC referenzierbar wäre),
also keine Netzwerkfade oder so virtuelle Pfade wie Desktop, Bibliotheken, Computer, Systemsteuerung (siehe Explorer).

Und ja, das können auch Links auf Netzlaufwerke sein, wenn sie z.B. via Subst als "Verzeichnis" in einer Partition gemappt wurden.

[Guido Eisenbeis]

Hallo himitsu.

Das verwirrt mich noch mehr. UNC-Pfade sind doch Netzwerkpfade, oder nicht!?

Könntest du das bitte anders beschreiben? Ich gehe mit gutem Beispiel voraus und formuliere meine Frage um: Was sind Einträge des Dateisystems und was nicht?

[himitsu]

Wenn sich der UNC-Pfad auf ein lokales Verzeichnis bezieht, dann gibt es einige Funktionen, welche den auflösen und dann ist es wieder ein Pfad im lokalen Dateisystem.
Also ja, UNC ist ein Netzwerkpfad, aber es kommt dann drauf an wer ihn wie verwendet.

Alles was sich direkt auf etwas in einer lokalen "Partition" bezieht und mit X:\ beginnt, also über einen lokal installierten Dateisystemtreiber läuft, entspricht diesem lokalen "Dateisystem" (ForceFileSystem).
RAM-Laufwerke und andere virtuelle Laufwerke einbezogen.

Dieser Dialog arbeitet mit IShellItem und dort kann man auch mit virtuellen "Verzeichnissen" arbeiten, welche ihre Daten aus anderen Quellen beziehen.
Beispiele sind sowas wie Desktop, Netzwerk, Bibliotheken, Computer, Systemsteuerung
oder z.B. die ZIP-Folder, wo der Explorer/ÖffnenDialog den Inhalt von ZIP-Dateien als "virtuelles" Unterverzeichnis anzeigt.


Im Großen und Ganzen braucht man an diesen Optionen nicht rumzuspielen, da die meißten Dateifunktionen mit fast Allem zurecht kommen, außer
* Einschränkung auf Verzeichnisse (Dateien ausblenden), um den Dialog zur Verzeichnisauswahl zu benutzen (wesentlich intuitiver und einfacher als die anderen FolderDialoge)
* FolderExists- und FileExists-Checks beim Öffnen, um nachträglich nicht extra prüfen zu müssen
* FileCreateTest ... nja, hier muß man aufpassen, bei WriteOnly-Verzeichnissen, also den am Besten erst beim nachfolgenden FileCreate/Open abfangen (Fehlerprüfung beim Erstellen)

[Guido Eisenbeis]

Wow, ein recht kompliziertes Thema, das wirklich nicht einfach zu erklären ist!

@himitsu

Vielen Dank für die gute Erklärung! Zwar knickt und knackt es in meinem Gehirn immer noch, aber ich bin der Sache nun etwas mehr auf der Spur. :)

Wie sieht das für meinen anfangs erwähnten Dialog zum Auswählen von Ordnern (TFileOpenDialog) aus? Ist fdoForceFileSystem für irgendwas sinnvoll? Bei meinen Tests kann ich keinen Unterschied feststellen, ob mit oder ohne fdoForceFileSystem. (Win 10 x64, Delphi 10.3)

[himitsu]

Es kommt drauf an.
Ordnerauswahl für einen Schreibzugriff ausschließlich auf lokale Pfade, da könnte fdoForceFileSystem nicht schaden. (Lesen geht fast immer, aber schreiben eventuell nicht ... siehe HTTP)

Ich persönlich hab diese Option noch nie benutzt und es gab bissher auch noch keine Probleme.

ofPathMustExist aktiviere ich eigentlich immer. (neue Verzeichnisse müssen dann vorher explizit erstellt werden, was in dem Dialog ja auch geht)
Für Öffnendialoge ist ofFileMustExist immer aktiv, weil die Datei muß ja sowieso existieren und der Fehler wird sofort gemeldet.
Bei Speicherndialogen nutze ich machmal ofOverwritePrompt, damit der Nutzer nicht irgendwas "ausversehn" bzw. unbemerkt überschreibt. (es sei denn Überschreiben ist das Standardverhalten)
ofNoTestFileCreate ist auch nahezu immer gesetzt, denn muß man bei WriteOnly-Laufwerken beachten, was z.B. auch auf ein Netzlaufwerk zum NAS zutrifft oder ganz speziell auf WORM, welche eine Versionierung vornimmen.
(bei ofNoTestFileCreate erstellt und löscht der Dialog die Datei einmal, was blöd endet, wenn sich die Datei nicht mehr löschen oder verändern lässt
und auch im Log tauchen dann unnötige Zugriffe auf)

Wie gesagt, meistens wird fdoForceFileSystem nicht benötigt. Es wäre auch etwas hinderlich, wenn man Netzwerkpfade erlauben möchte.
CreateFile, TFileStream, LoadFromFile usw. kommen mit sehr ... sehr viel zurecht, wie UNC und sogar FTP, HTTP usw. wurde von Microsoft implementiert.

Ich weiß nicht mehr wie, aber man kann in diesem Dialog auch Drucker und Scanner auflisten lassen.
Beim Speichern einer Datei würde es mit soeinem Pfad eventuell ein paar Probleme geben.

Falls du mit IShellItem und dessen API und Stream-Zugriffen arbeitest, dann kann praktisch alles verwendet werden.
.FileName -> .ShellItem
.Files -> .ShellItems

Aber standardmäßig listet dieser Dialog sowieso nur Dinge auf, zu denen es einen schönen Pfad im Dateisystem gibt, welcher sich über .FileName auslesen und mit den meisten FileAPIs verwenden lässt.
Deswegen bemerkst du bei deinen Tests wohl auch keinen Unterschied.

[Guido Eisenbeis]

Zitat:

Zitat von himitsu (Beitrag 1454271)

Aber standardmäßig listet dieser Dialog sowieso nur Dinge auf, zu denen es einen schönen Pfad im Dateisystem gibt, welcher sich über .FileName auslesen und mit den meisten FileAPIs verwenden lässt.
Deswegen bemerkst du bei deinen Tests wohl auch keinen Unterschied.

Somit lasse ich fdoForceFileSystem beim Aufruf weg. Danke bis hierhin! :thumb:

Du hast einen wichtigen Punkt angesprochen: ofNoTestFileCreate (besser gesagt: Testen auf Schreibrechte ist gewünscht).

Wie du dir wohl schon aus meinen beiden Threads zusammengereimt hast, kann der User mit meinem Programm einen Ziel-Ordner auswählen (TFileOpenDialog, fdoPickFolders), in den dann Dateien und Unter-Ordner kopiert werden. Dazu wäre ist es notwendig, Schreibrechte im Ziel-Ordner zu haben. Kann man das gleich mit dem TFileOpenDialog prüfen? Gibt es vielleicht ein Flag, mit dem nur Ordner mit Schreibrecht ausgewählt werden können? Falls nicht, mache ich dafür einen anderen Thread auf (falls ich's nicht selbst rausfinde). :wink:

Wichtig: Schreibrecht ist mit normalen User-Rechten gemeint, also ohne Admin-Rechte.

[himitsu]

Ich wusste es doch. :oops:
Hatte es anfangs auch andersrum geschrieben und dacht mir dann, andersrum klingt es richtiger. (nächstes Mal am Vortag weniger saufen)

Ich weiß allerdings nicht, ob das TestFileCreate auch bei der Ordnerauswahl gemacht wird.
Müsste man mal nachsehn, ob und mit welchem Dateinamen. (beim Speicherndialog ist es der Name der eingegebenen Datei)

Zugriffsrechte selbst werden vom Dialog nicht geprüft. Allerdings besteht die Möglichkeit über Events auf die Dateiauswahl/-eingabe zu reagieren und vor dem OK zu prüfen.
Wobei ich es inzwischen aufgegeben hab Rechte detailiert zu prüfen, da ich dabei garantiert irgendwas vergesse und die Prüfung falsche Ergebnisse liefert ... hier einfach die Datei öffnen/speichern und wenn es knallt, dann die passende Fehlermeldung.
Die Leseberechtigung der übergeordneten Verzeichnisse werden indirekt geprüft, da sich die Verzeichnisse dann nicht öffnen und somit untergeordnete Dateien/Verzeichnisse nicht auswählen lassen. (Eingeben kann man aber alles, inkl. Pfad unten im Edit ... darum hab ich auch immer das ofPathMustExist aktiv)