Dateien mit langen Pfaden bzw. Dateinamen kopieren

[et2004]

Hallo Zusammen!

Ich habe folgende Aufgabe: aus einem Delphi Programm müssen Dateien von einem PC auf eine externe USB-Festplatte kopiert werden. Dabei muss die Ordner-Struktur auf der USB-Festplatte 1-zu-1 abgebildet werden.

Mit normalen Dateinamen funktionieren Befehle wie ForceDirectory, CopyFile und SHFileOperation völlig richtig. Wenn jedoch eine Datei mit langem Pfad (mehrere Unterordner) kopiert werden muss, dann versagen diese Befehle und bringen Fehlermeldungen wie: "Dateiname zu lang"

Als Beispiel:

die Quelldatei:

"D:\Info\Windows\Server-2003\Windows 2003 Server Infos\323360 - SO WIRD'S GEMACHT Installieren und Konfigurieren eines DHCP-Servers in einer Active Directory-Domäne in Windows Server 2003-Dateien\1ptrans.gif"

muss nach

"F:\Info\Windows\Server-2003\Windows 2003 Server Infos\323360 - SO WIRD'S GEMACHT Installieren und Konfigurieren eines DHCP-Servers in einer Active Directory-Domäne in Windows Server 2003-Dateien\1ptrans.gif"

kopiert werden.

Versucht habe ich es auch mit TFileStream, dabei wird aber eine Schutzverletzung ausgelöst sobald ich versuche die Zieldatei zu öffnen (TFileStream.Open).

Gruss et2004 :-(

[marabu]

Hi,

fährst du denn auf deinem USB Device auch ein file system, welches so lange Dateinamen unterstützt?

Grüße vom marabu

[Robert Marquardt]

Da hat Marabu ganz recht. DieUSB-Festplatte ist vermutlich mit FAT32 formatiert, da dies das beste Austauschformat ist.
Dort sind aber nur Dateinamen mit 31 Zeichen erlaubt, waehrend NTFS 255 Zeichen erlaubt.

Wer macht eigentlich so lange Namen (ausser Word)? Das ist einfach unmoeglich korrekt einzugeben.

[et2004]

Hallo marabu!

Beide Platten haben NTFS als Dateisystem. Der Fehler tritt sowohl unter WinXP als auch auf dem Server 2003 Standard auf.

Ich habe beim Debuggen folgenden Effekt festgestellt: ich kann auf der Ziel-Festplatte den langen Ordner nicht mit ForceDirectory erstellen. Deswegen habe ich mir diese Funktionalität nachgebaut und erstelle die Ordner mit CreateDirectory. Bei dem letzten und längsten Ordner (s.O.) steigt auch CreateDirectory mit einer Fehlermeldung aus. Ich habe aber ein WorkAround und erstelle mir einen Dummy-Ordner mit einem kurzen Namen und setze dann RenameFile ein und habe somit einen Ordner mit langen Namen.

Gruss et2004

[et2004]

Hallo Robert Marquardt!

Die langen Dateinamen stammen aus einem Windows Administrator Forum (HTML-Seite welche mit dem IE geespeichert worden ist).

Gruss et2004

[himitsu]

Also sooo lange Dateinamen sind ja icht nur unpracktisch zu lesen, sondern es könnte auch noch andere Probleme geben.

In Windows kann eine Verzeichnisangabe, incl. Laufwerk, Dateiname und dem abschließendem #0, maximal 260 Zeichen lang sein.

Wenn jetzt schon "nur" der Dateiname extrem lang ist, dann kann es sein, das die estlichen Informationen nicht mehr in den Puffer reinpassen.

Aber wenn die Pfadangabe gerade noch so Platz habt, dann können dieses unter Umständen in einem anderem Verzeichnis nicht mehr ausreichend sein.

Sollte z.B. deine USB-Festplatte intern, oder sichtbar nicht direckt über 'ne kurze Laufwerkskennung angesprochen werden wird es eng.



PS: I selber hatte auch mal nach 'nem ähnlichem Fehler gesucht.
Beim Kopieren wurde nach 'ner Weile, ohne erstichlichen Grund, abgebrochen.
Am Ende war es so, das ich meine Dateien zum Sichern in ein Unterverzeichnis einer anderen Platte kopieren wollte, die Originaldateien lagen allerdings im Root-Verzeichnis ... und nur ja, durch die dadurch verlängerte Pfadangebe hab ich halt an die Grenze durchstoßen -.-''

[et2004]

Ich kann es leider nicht beeinflussen welcher Benutzer sich welche Dateien auf den Datenserver speichert. Man kann es den Leuten immer wieder sagen: Bitte kurze Dateinamen eintragen ... nach einer Woche habe die alles wieder vergessen (--> allgemeine Admin-Probleme ;-) )

Mir geht es dabei nur um die Sicherung der Daten und mein Programm sollte dann alle Dateien auf die externe Platte übertragen (egal wie lang die Dateinamen sind).

[marabu]

Zitat:

Zitat von et2004

Ich habe aber ein WorkAround und erstelle mir einen Dummy-Ordner mit einem kurzen Namen und setze dann RenameFile ein und habe somit einen Ordner mit langen Namen.

Wenn du eh schon ein Programm einsetzt um die gespeicherten Web-Seiten zwischen Platte und USB device auszutauschen, dann würde ich versuchen die vom Explorer vorgeschlagenen und vom Benutzer unglücklicherweise akzeptierten Namen wieder zu kürzen. Ist nicht so schwer. Der Name der Datei steht ja immer noch im TITLE element der gespeicherten Seite.

marabu

[Christian Seehase]

Moin et2004,

das Problem ist wohl, dass Du nicht 260 Zeichen, sondern 260 Byte für den Pfad zur Verfügung hast.
Da es sich in der Regel aber wohl um Unicode handeln dürfte, hast Du nur die Hälfte davon an Zeichen zur Verfügung.
Solange ein einzelner Abschnitt nicht zu lang wird, kann man solche Strukturen anlegen, nur rauskopieren geht dann nicht mehr.
Unter Windows 2000 hatte ich schon den Effekt, dass der Explorer, ohne sinnvolle Fehlermeldung, zwangsweise beendet wurde.
Den gleichen Ordner dann über XP angezeigt (per Adminfreigabe das Laufwerk verbunden) gab es dann auch die entsprechende Fehlermeldung :?

[himitsu]

Soweit ich das bisher mitbekommen hab, werden auch für Unicode 260 Zeichen verwendet (520 Byte) ... jednefallt hatte ich in dieser Richtung noch keine Probleme.

[Christian Seehase]

Moin Himitsu,

ging bei mir definitiv nicht.
Ich habe mir nicht die genaue Anzahl der Zeichen gemerkt, aber bei einer gesamten Pfadlänge von etwas unter 130 Zeichen liess sich die Datei nicht mehr kopieren (im Explorer, XP Pro SP2).
Dummerweise ohne korrekte Fehlerangabe :?

[himitsu]

Ist ja wirklich eigenartig, denn beim Aufbau meiner Files-Unit hatte ich extra getestet, ob der FileNamePuffer der WinAPI auch in den Unicode-Versionen mit den 260-Chars arbeitet, da dises ja nirgendwo beschrieben ist.

Ich hatte nur manchmal ein Prolem bei den maximalen 259 Zeichen (ohne das abschließende #0) ... unter Umständen werden sowohl bei Ansi, als auch bei Wide maximal nur 258 Zeichen angenommen.

Getestet wurden damals von mir einige FAT12, FAT16, FAT32, NTFS4, NTFS5 und was mir sonst noch für Dateisysteme unter die Finger geraten sind und das Meiste davon war auf 'nem WinXP Pro ohne ServicePacks.

[Christian Seehase]

Moin Himitsu,

also ich hatte den Effekt unter W2K SP4 und WXP SP2.

Zitat:

Zitat von Himitsu

als auch bei Wide maximal nur 258 Zeichen angenommen.

was ja bei Wide auch logisch wäre, denn hier endet der String ja mit #00#00 (also zwei Nullbytes).

[himitsu]

Dat stimmt ja wiederum auch nicht,

den bei Wide sind es zwar zwei #0, allerdings zwei Bytes ... in WideChar gerechnet ist das aber auch nur ein Zeichen, womit man ja eigentlich wiederum auf die maximalen 259 WideChar-Zeichen kommen würde :gruebel:


I hab hier zwar 'nen Win2K-Rechner, allerdings kein Delphi zum testen, oder'n Prgramm, was das machen könnte.

[Christian Seehase]

Moin Himitsu,

Zitat:

Zitat von himitsu

Dat stimmt ja wiederum auch nicht,

den bei Wide sind es zwar zwei #0, allerdings zwei Bytes ... in WideChar gerechnet ist das aber auch nur ein Zeichen, womit man ja eigentlich wiederum auf die maximalen 259 WideChar-Zeichen kommen würde :gruebel:

Stimmt auch wieder. :wall:

Zitat:

Zitat von Himitsu

I hab hier zwar 'nen Win2K-Rechner, allerdings kein Delphi zum testen, oder'n Prgramm, was das machen könnte.

Wie schon weiter oben erwähnt:
Das Problem ist bei mir nicht in einem Delphi-Programm aufgetreten, sondern direkt im Explorer.
Anders gesagt: Windows hatte da schon ein Problem. :?

[himitsu]

Na ja, vielleicht war da auch nur'n Fehler in der Ansi-UnicodeConvertierung ... denn wenn es im Ansi funktioniert, dann sollte es doch auch im Wide laufen, denn Windows verwendet doch intern auch die Wide-Version ... jedenfalls werden die Daten im Dateisystem nur als Wide gespeichert?