Sicherung von Dateien mit langem Pfaden/Namen - bei Windows /Linux im Vergleich

[say_hello]

Ich bin als Windows-Nutzer so gewöhnt daran - ich kann es mir fast nicht vorstellen, bzw. bin mißtrauisch.

Mal ein Beispiel: C:\Meine_Dateien\Neu\Externe_Quelle\Information\Aus _dem_Internet\Deutsch\Tests\Software\LinuxOSX\Backup-Programme-SuseLinux2018-02-13\01_files\200x1130.jpg

Frage: kann es denn sein dass da die Sicherung - solange sie auf Linux läuft sehr problemlos ist.

Aber wenn man solche Dateien von einem Windows-System (sagen wir win 7) herunterkopieren will - dann steckt man voller Probleme.

Also - nochmals zugespitzt - ist das unter Linux etwa übrerhaupt kein Problem - aber auf win-Systemen muss man sehr darauf achten, dass es ___nicht__ zu langen Pfaden kommt?

Frage: wenn da sol ist - kann es sein dass es ggf. für Windows eine Abhilfe / Reparaturmethode gibt!?

Freue mich, von Euch zu hoeren.

Viele Grüße

NOCHWAS; siehe:das hier hab ich noch gefunden; http://de.wikipedia.org/wiki/HFS_plus

 

[Thyrion]

1) Ich weiß jetzt nicht, wie du auf HFS+ kommst, aber das hat erstmal weder mit Linux noch mit Windows was zu tun - das kommt bei MacOS/iOS zum Einsatz.

2) Zum Thema Dateinamen und Längen unter Windows, siehe Naming Files, Paths, and Namespaces (Windows)

Kurz: Die maximale Länge von Laufwerksbuchstaben+Pfad+Dateiname (inkl. Trennzeichen) ist/war in Windows auf 260 Zeichen limitiert - ab Win10 soll das aber der Vergangenheit angehören (dann sind es knapp 32.000 Zeichen, ausprobiert habe ich es aber noch nicht). Behelfen kann man sich aber mit Subst oder Netzwerk-Freigaben.
Dann sei weiterhin zu beachten: FAT/FAT32/exFAT und NTFS unterscheiden nicht zwischen Groß- und Kleinschreibung, wohingegen Ext2/3/4 und diverse andere unter Unixoiden verwendeten Dateisysteme das sehr wohl tun. Desweiteren werden Rechte und Nutzer-/Gruppenzugehörigkeiten nicht mehr übereinstimmen - um das zu umgehen, würde ich die Linux-Sicherung in eine Tar-Datei stecken - und vermutlich noch gzippen.

 

[say_hello]

hallo und guten Morgen Thyrion,



vielen Dank für die schnelle Antwort und die wertvollen Hinweise zu MS-Windows. Das ist sehr sehr hilfeich!!

Frage: Bei win 7 scheint es also ein echtes Problem zu sein -
Bei/ab Win 10 ist das zunehmend kein Problem mehr.

Bei Linux - da scheint es m.E. auch kein Problem aufzuwerfen - (zb. OpenSuse LEAP 42 bzw OpenSuse 13.xy

Also ich koennte bei Linux Daten sichern - z.b. auf einen USB Stick die einen superlangen PFAD oder Namen haben...:


Mal ein Beispiel ( C:\)) Meine_Dateien\Neu\Externe_Quelle\Information\Aus _dem_Internet\Deutsch\Tests\Software\LinuxOSX\Backup-Programme-SuseLinux2018-02-13\01_files\200x1130.jpg

a. das ist bei win-sieben ggf ein Problem !?
b. das tellt bei Linux wohl kein Prlblem da.!?

 

[Thyrion]

Bei dem Beispiel hast du noch 103 Zeichen Platz - das ist schon noch einiges.

Und wenn du vorher in einer Konsole

subst X: "C:\Meine_Dateien\Neu\Externe_Quelle\Information\Aus_dem_Internet\Deutsch\Tests\Software\LinuxOSX\Backup-Programme-SuseLinux2018-02-13"

machst und die Dateien (01_files\*, etc.) dann nach X: kopierst, hast du wieder 256 Zeichen Platz (4 sind für "X", ":", "\" und ein terminales NUL-Zeichen schon verbraucht).

Danach dann den Subst mit

subst X: /d

wieder löschen.

Um auf die Dateien mit "überlangem" Pfad wieder zuzugreifen, vorher erneut den Subst machen.

 

[original-mei]

... Die maximale Länge von Laufwerksbuchstaben+Pfad+Dateiname (inkl. Trennzeichen) ist/war in Windows auf 260 Zeichen limitiert...

260? Waren es nicht 255 (2^8-1)?

 

[Thyrion]

Wie du der Quelle oben entnehmen kannst, nein - aber 256 sind frei nutzbar, die übrigen 4 sind die Mindestlänge.

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)