Hallo, ich habe eine TAR-Datei (gepackt unter Windows) und möchte sie unter Linux entpacken. Es kommt jedoch eine Fehlermeldung, dass der Dateiname zu lang ist! Hat jemand eine Idee was ich tun kann (außer ein Windows-System nutzen)? Gruß Dennis
Ich nehme mal an, das Du mit gnu tar unter Linux arbeitest. Wenn alle Dateinamen mit einem (oder mehreren) Unterverzeichnis(sen) beginnen, dann ist die Option --strip-components=XXX für Dich interessant. Mit dieser Option werden die XXX Verzeichnisse am Anfang des Dateinamens angeschnitten. Z.B: aus "dummy/test/hallo/welt.c" würde mit --strip-components=2 nur noch "hallo/welt.c". Alternativ kann Dir auch die Option --xform=AUSDRUCK weiterhelfen: Damit kannst Du mit einem Regulärem Ausdruck den Dateinamen verändern (ähnlich wie sed s/AAA/BBB/). Informationen zu beiden Optionen findest Du hier: http://www.gnu.org/software/tar/manual/html_section/transform.html Gruß Chris
Hmm, mal ein paat Fakten zusammentragen: In der Windows Oberfläche ist ohne Tricks der gesamte Pfad auf 260 Zeichen beschränkt. Hat man längere Pfade wirds schon in Windows selbst unhandlich. Din einzelnen Kompoenenten eines Pfades sind auf 255 Bytes beschränkt. Allerdings bezieht sich das auf Unicode. In Linux sind die Komponenten eines Pfades auf 255 Bytes beschränkt. Der Pfad darf viel länger werden. Der klassische TAR kann Pfade bis maximal 100 Bytes speichern. Erweiterte Versionen bis irgendwas zwischen 100 und 255 Bytes, je nach Inhalt des Pfaded. Für längeren Kram hat man sich gelegentlich exquisit hässliche Tricks einfallen lassen. Ergo: Beim normale TAR kann das Problem eigentlich überhaupt nicht auftreten.
Mehr Details wären hilfreich.... Evtl. werden die Dateien in einem Verzeichnis entpackt, das bereits einen recht langen Pfad hat, und zusammen mit den entpackten Pfaden wird es insgesamt zu lang?
Klaus Wachtler schrieb: > Evtl. werden die Dateien in einem Verzeichnis entpackt, das bereits > einen recht langen Pfad hat, und zusammen mit den entpackten Pfaden wird > es insgesamt zu lang? Das Risiko hat man vorzugsweise umgekehrt, weil die Pfadlänge in Windows, je nach API, auf 260 Zeichen begrenzt ist. Wenn die Wurzel bereits 200 mitbringt wirds eng.
A. K. schrieb: > Windows, je nach API, auf 260 Zeichen begrenzt ist. Wenn die Wurzel > bereits 200 mitbringt wirds eng. Wenn Dein System meterlangen Ordner-Namen ausgibt, bleibt nicht mehr viel für den restlichen Dateinamen übrig. Also Wurzelnah nochmals Ordner anlegen und dort testen. Zu langer Namen könnte auch Dein Backup ins schleudern bringen. Kontrolliere Dein Backup öfter auf Vollständigkeit!
Hallo nochmal, an Windows kann es doch eigentlich nicht liegen. Hier wurde das Archiv doch erstellt?! Ich versuche es in mein Home-Verzeichnis zu entpacken (/home/xxxxxx/). Zusammen mit den Dateinamen sind es (beispielhaft) 210 Zeichen. Sollte nach meiner Meinung also gehen. Gruß Dennis Btw.: Meine Backups sind hervorragend...
Folgendes Verzeichnis
1 | $ tree |
2 | . |
3 | └── test |
4 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
5 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
6 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
7 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
8 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
9 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
10 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
11 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
12 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
13 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
14 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
15 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
16 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
17 | └── 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 |
18 | |
19 | 14 directories, 1 file |
kann ich unter Linux mit GNU-tar 1.27.1 problemlos taren und wieder enttaren. Die einzelnen Verzeichnisnamen und der Name der Datei im innersten Verzeichnis sind jeweils 100 Zeichen lang, die Pfadlänge liegt somit deutlich ober dem in Windows erlaubten Maximum. Welches Tar-Programm hast du unter Windows verwendet? Vielleicht ist es an irgendeiner Stelle nicht ganz mit GNU-Tar kompatibel.
Dennis S. schrieb: > Btw.: Meine Backups sind hervorragend... DAS weisst Du erst, wenn Du sie gebraucht hast oder versuchsweise Dein System woanders wiederhergestellt hast. ;-( wendelsberg
Das kann auch vom Dateisystem und vom Speicherort (resultierende Gesamtpfadlänge) abhängen. Testweise mal direkt in /tmp entpacken? Ich hatte das Problem mal mit einem SVN, das auf einer NTFS-Partition lag. Problem war der nicht mehr ganz taufrische NTFS-Treiber. Einmal Kompilieren der aktuellen Version, und schon ging das "svn update" wieder, ohne sich über die zu langen Dateinamen zu beschweren.
wendelsberg schrieb: > Zeig mal die Originalfehlermeldung. > > wendelsberg "Fehler beim Öffnen der Datei <<Dateiname_inkl_Pfad>>: Der Dateiname ist zu lang." Möglicherweise ist es wirklich eine Inkompatibilität von dem Windows-Tar..
Da der Name ja offenbar drinsteht: Wie lang ist zu lang, d.h. wie sieht der aus? Kannst ihn ja x.en.
Dennis S. schrieb: >> Zeig mal die Originalfehlermeldung. > > "Fehler beim Öffnen der Datei <<Dateiname_inkl_Pfad>>: Der Dateiname ist > zu lang." Möglicherweise ist es wirklich eine Inkompatibilität von dem > Windows-Tar.. > Okay, Korrektur: in /tmp kann ich es entpacken! Dann liegt es auch nicht an tar, sondern am NTFS(?) Treiber für Linux. Wie es aussieht, liegt das .tar Archiv auf dem Windows-Filesystem und da in tief verschachtelten Verzeichnissen? XL
Axel Schwenke schrieb: > Dann liegt es auch nicht an tar, sondern am NTFS(?) Treiber für Linux. Woher nimmst Du bloß diese Phantasie? Lies: Beitrag "Re: Entpacken von TAR-Archiv, Dateinamen zu lang" Er versuchte zunächst, es in seinem Home-Verzeichnis zu entpacken. Oder glaubst Du jetzt, dass sein Home auf einem NTFS-Verzeichnis liegt? ;-)
Frank M. schrieb: > Er versuchte zunächst, es in seinem Home-Verzeichnis zu entpacken. Oder > glaubst Du jetzt, dass sein Home auf einem NTFS-Verzeichnis liegt? ;-) Man beachte den Unterschied zwischen dem Archiv und dem Ziel, wo die entpackten Dateien hin sollen: Axel Schwenke schrieb: > Wie es aussieht, liegt das .tar Archiv auf dem Windows-Filesystem ^^^^^^^^^^^^^^^ Tatsächlich schreibt Dennis nirgends, ob ob sich die Fehlermeldung auf den Namen des Archivs selbst oder den einer zu entpackenden Datei bezieht. Auch bei Dennis S. schrieb: > in /tmp kann ich es entpacken! bleibt unklar, ob das Archiv oder das Ziel in /tmp ist.
Rolf Magnus schrieb: > [...] bleibt unklar, ob das Archiv oder das Ziel in /tmp ist. Ich hatte das so verstanden: cd /home/xxxxx tar x.... foo.tar # schlägt fehl cd /tmp tar x.... foo.tar # funktioniert Aber wer weiß. Die Fehlermeldung ist da nicht präzise genug. Irgendwo kann ich mir auch nicht vorstellen, dass der Ort, wo ich gerade die tar-Datei auspacken will, eine Rolle spielt. Der Gesamtpfad wird durch /home/xxxxx nur unwesentlich länger als durch /tmp. Ausserdem: wo spielt der Gesamtpfad unter Linux überhaupt eine Rolle für tar? tar sollte sich eigentlich für das aktuelle Arbeitsverzeichnis einen Kehricht scheren. Der TO könnte natürlich unter /home ein anderes Filesystem, welches keine längeren Dateinamen unterstützt, gemounted haben. Das wäre fies. ;-)
:
Bearbeitet durch Moderator
Falls es für die Diskutierenden noch von Interesse ist: - Die Fehlermeldung bezog sich auf den Dateinamen - Archiv-Verzeichnis und Entpack-Ziel-Verzeichnis waren immer identisch Die Situation war so wie von Frank M. beschrieben. Wobei, aber das Dateisystem ebenfalls identisch sind! ;-) Gruß Dennis
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.