filesystem encoding und tar
Jürgen Richtsfeld
ich hab vor kurzem daten von einem pc (debian sid, vor ca. 4 jahren
installiert, locale ist de_AT, fs ist xfs) zu einem anderen (ubuntu 9.10,
vor wenigen wochen installiert, loacle ist en_US.UTF8, fs ist ext4) mittels
tar und netcat übertragen (weil das extrem schnell ist).
verzeichnisse mit umlauten wurden fehlerhaft angelegt, die files darin
fehlten. ich habe natürlich in der shell, in der ich gearbeitet habe auf
beiden systemen versucht, die locale auf eine utf8 zu setzen - hat aber
nichts gebracht.
bisher fand ich im netz keine lösung für mein problem. auch kann man
scheinbar beim mount eines xfs nicht das encoding für filenames angeben (was
bei fat und ntfs scheinbar schon geht).
schließlich habe ich die daten mit rsync auf eine externe harddisk
übertragen, und am zielsystem mit 'convmv' konvertiert und dann auf das
zielsystem kopiert.
tar ist ja eigentlich zum systembackup gemacht, und ich währe beim restore
überrascht wenn dann solche probleme auftreten, darum denke ich dass es für
das problem eine lösung geben muss.
nun also die frage:
wie kann man mit tar files übertragen, die bei einem anderen fs encoding
wieder hergestellt werden können.
jürgen
Andreas Leitgeb
> verzeichnisse mit umlauten wurden fehlerhaft angelegt, die files darin
> fehlten.
Wenn "fehlerhaft" bedeutet, dass anstelle der Umlaute (und manchmal auch
etwaiger folgebuchstaben) irgendwelche Schmierzeichen entstanden, dann ist
das eben das symptom eines encoding-mismatches.
Wenn bei einem Kommando a la
tar xvf -
einzelne Dateien komplett fehlen, dann wäre das ein Bug in tar.
Wenn das Kommando hingegen:
tar xvf - directöry
lautete, dann ist das aus tar-sicht so als hättest
du ein verzeichnis "schwampf" entpacken wollen. tar
weiss nicht, dass das (utf-8 kodierte) directöry von
der kommandozeile das gleiche sein soll, wie das
(iso8859-15 kodierte) directöry im tar-file drin.
Jürgen Richtsfeld
> Jürgen Richtsfeld <juergen.r...@gmx.at> wrote:
>> verzeichnisse mit umlauten wurden fehlerhaft angelegt, die files darin
>> fehlten.
>
> Wenn "fehlerhaft" bedeutet, dass anstelle der Umlaute (und manchmal auch
> etwaiger folgebuchstaben) irgendwelche Schmierzeichen entstanden, dann ist
> das eben das symptom eines encoding-mismatches.
>
> Wenn bei einem Kommando a la
> tar xvf -
> einzelne Dateien komplett fehlen, dann wäre das ein Bug in tar.
nein, die files waren im archiv. beim ent-taren konnten files in directories
mit umlauten nicht erzeugt werden (vermutlich weil der erzeugte name nicht
mit dem namen im archiv zusammenstimmt).
>
> Wenn das Kommando hingegen:
> tar xvf - directöry
> lautete, dann ist das aus tar-sicht so als hättest
> du ein verzeichnis "schwampf" entpacken wollen. tar
> weiss nicht, dass das (utf-8 kodierte) directöry von
> der kommandozeile das gleiche sein soll, wie das
> (iso8859-15 kodierte) directöry im tar-file drin.
ok, das war auch meine vermutung. wie behebt man das problem?
Andreas Leitgeb
> Andreas Leitgeb wrote:
>> Wenn bei einem Kommando a la
>> tar xvf -
>> einzelne Dateien komplett fehlen, dann wäre das ein Bug in tar.
Ich glaube, ich habe mich unklar ausgedrückt.
Hast du beim *Auspacken* ein einzelnes Verzeichnis (mit umlauten
im namen) mit-angegeben, oder hast du *alles* auf einmal auspacken
wollen?
Wenn du mit Ersterem Probleme hattest, würd ich es mal mit Zweiterem
(also alles auspacken) versuchen.
Wenn du mit Zweiterem Probleme hattest, dann versuch mal vor das
tar ein LANG=C reinzu setzen: also statt netcat ... | tar ...
eben: netcat ... | LANG=C tar ...
> beim ent-taren konnten files in directories
> mit umlauten nicht erzeugt werden (vermutlich weil der erzeugte
> name nicht mit dem namen im archiv zusammenstimmt).
Das hätte aber zusammenstimmen müssen, wenn du alles in einem
Zug ausgepackt hättest. Das Verzeichnis hättest du dann im
Nachhinein auf richtige Umlaute umbenennen können.
Andreas Leitgeb
> tar ist ja eigentlich zum systembackup gemacht, und ich währe beim restore
> überrascht wenn dann solche probleme auftreten, darum denke ich dass es für
> das problem eine lösung geben muss.
Ich habe glaub ich diesen aspekt vorhin überlesen...
Dein Problem selbst ist ja schon gelöst, mit rsync und
convmv(letzteres kannte ich selber noch garnicht).
Es geht also ums Verständnis von encoding der filenames
in unix-filesystemen und den damit verbundenen Problemchen.
Für's verständnis ist jedenfalls wichtig zu wissen, dass
unix-filesystemen das encoding reichlich egal ist. Die
speichern prinzipiell nur byte-strings, und die Umsetzung
von den bytes zu buchstaben/zeichen ist Anwendungssache.
Anwendungen machen das in der regel abhängig von der
durch die LANG-variable festgelegten locale. (Ausser ein
paar uralte anwendungen, die z.b. noch fix iso-8859-1 als
encoding annehmen.)
Im tar-file sind also die originalen bytes gespeichert, und
wenn die am neuen, utf-8 basierten system entpackt werden,
gibt es ein paar möglichkeiten:
1) das entpacker-prog schreibt die bytes der dateinamen
1:1 ins filesystem, dann klappt zwar das entpacken,
aber die dateinamen erscheinen in dateimanagern (das
inkludiert auch "ls" :-) falsch.
2) das entpacker-programm erkennt die - gemäß versuchter utf-8
interpretation falschen - bytes, und konvertiert sie
intern nach utf-8
2a) es macht's richtig, dann klappt's und du hast korrekte
utf-8 konvertierte namen in den entpackten files&dirs
2b) es macht's falsch, und es kommt ein inkonsistenter
mischmasch aus iso-8859 und utf-8 heraus, wo directories
in einem encoding angelegt, aber im anderen encoding
als pfad für die inneren Dateien verwendet werden.
Ich hätte tar eigentlich in der kategorie "1)" vermutet, aber nach
deinen Schilderungen scheint es sich eher nach "2b)" zu verhalten.
Hinzu kommt dann noch, wenn man nicht einfach nur entpackt, sondern
eben nur Teile entpacken will (siehe "schwampf"-kommentar im anderen
Posting), aber ich bin mir nicht sicher, ob das nun in deinem Fall
relevant ist. Wenn ich ein tar-file per netcat über's LAN schicke,
würde ich lieber beim Einpacken schon filtern, und nicht erst beim
Auspacken. Außer natürlich, ich habe dich missverstanden.
Jürgen Richtsfeld
> Jürgen Richtsfeld <juergen.r...@gmx.at> wrote:
>> Andreas Leitgeb wrote:
>>> Wenn bei einem Kommando a la
>>> tar xvf -
>>> einzelne Dateien komplett fehlen, dann wäre das ein Bug in tar.
>> nein, die files waren im archiv. [...]
>
> Ich glaube, ich habe mich unklar ausgedrückt.
>
> Hast du beim *Auspacken* ein einzelnes Verzeichnis (mit umlauten
> im namen) mit-angegeben, oder hast du *alles* auf einmal auspacken
> wollen?
ich hab das ganze tar entpackt, nicht teile davon.
>
> Wenn du mit Ersterem Probleme hattest, würd ich es mal mit Zweiterem
> (also alles auspacken) versuchen.
wie gesagt, ich hab *nur* das gemacht.
>
> Wenn du mit Zweiterem Probleme hattest, dann versuch mal vor das
> tar ein LANG=C reinzu setzen: also statt netcat ... | tar ...
> eben: netcat ... | LANG=C tar ...
das werde ich demnächst noch probieren.
>
>> beim ent-taren konnten files in directories
>> mit umlauten nicht erzeugt werden (vermutlich weil der erzeugte
>> name nicht mit dem namen im archiv zusammenstimmt).
das ist auch meine vermutung.
>
> Das hätte aber zusammenstimmen müssen, wenn du alles in einem
> Zug ausgepackt hättest. Das Verzeichnis hättest du dann im
> Nachhinein auf richtige Umlaute umbenennen können.
ja, ich habe alles in einem zug ausgepackt. und genau das verstehe ich auch
nicht. ich vermute, dass die angelegten verzeichnisse zeichen enthielten,
die ungültig für filenames sind (wobei sie angelegt wurden, aber es war
durchaus nicht leicht, sie zu löschen).
wie oben gesagt, ich werde demnächst noch versuchen, auf beiden seiten dem
tar ein LANG=C mitzugeben, dann melde ich mich wieder.
Jürgen Richtsfeld
> Jürgen Richtsfeld <juergen.r...@gmx.at> wrote:
>> tar ist ja eigentlich zum systembackup gemacht, und ich währe beim
>> restore überrascht wenn dann solche probleme auftreten, darum denke ich
>> dass es für das problem eine lösung geben muss.
>
> Ich habe glaub ich diesen aspekt vorhin überlesen...
> Dein Problem selbst ist ja schon gelöst, mit rsync und
> convmv(letzteres kannte ich selber noch garnicht).
>
> Es geht also ums Verständnis von encoding der filenames
> in unix-filesystemen und den damit verbundenen Problemchen.
>
> Für's verständnis ist jedenfalls wichtig zu wissen, dass
> unix-filesystemen das encoding reichlich egal ist. Die
> speichern prinzipiell nur byte-strings, und die Umsetzung
> von den bytes zu buchstaben/zeichen ist Anwendungssache.
das aussehen der bytes hängt aber vom encoding ab. und ich bin sicher, dass
das quellsystem iso-8859-1 und das zielsystem utf8 verwendet. meine annahme
wird auf jeden fall bestätigt durch die existenz von convmv und auch dadurch
das es bei mir funktioniert hat. convmv dürfte die filenames (byte-folgen)
vom filesystem ändern, da es unabhängig von LANG variablen funktionierte.
des weiteren vermute ich, dass es eine kerneleinstellung ist, in welchem
encoding filenames gespeichert werden müssen, dazu habe ich aber leider noch
nichts gefunden.
>
> Anwendungen machen das in der regel abhängig von der
> durch die LANG-variable festgelegten locale. (Ausser ein
> paar uralte anwendungen, die z.b. noch fix iso-8859-1 als
> encoding annehmen.)
>
> Im tar-file sind also die originalen bytes gespeichert, und
> wenn die am neuen, utf-8 basierten system entpackt werden,
> gibt es ein paar möglichkeiten:
> 1) das entpacker-prog schreibt die bytes der dateinamen
> 1:1 ins filesystem, dann klappt zwar das entpacken,
> aber die dateinamen erscheinen in dateimanagern (das
> inkludiert auch "ls" :-) falsch.
ich vermute, dass genau das stattgefunden hat. dieses vorgehen erachte ich
als gefährlich, da die bytefolgen in einem anderen encoding durchaus
illegale zeichen beinhalten können.
> 2) das entpacker-programm erkennt die - gemäß versuchter utf-8
> interpretation falschen - bytes, und konvertiert sie
> intern nach utf-8
naja, dazu ist es notwendig, das encoding im tar file zu kennen. gefragt
wurde ich danach nicht, und ich glaube nicht dass es erkannt/geschätzt wird.
> 2a) es macht's richtig, dann klappt's und du hast korrekte
> utf-8 konvertierte namen in den entpackten files&dirs
> 2b) es macht's falsch, und es kommt ein inkonsistenter
> mischmasch aus iso-8859 und utf-8 heraus, wo directories
> in einem encoding angelegt, aber im anderen encoding
> als pfad für die inneren Dateien verwendet werden.
>
> Ich hätte tar eigentlich in der kategorie "1)" vermutet, aber nach
> deinen Schilderungen scheint es sich eher nach "2b)" zu verhalten.
>
> Hinzu kommt dann noch, wenn man nicht einfach nur entpackt, sondern
> eben nur Teile entpacken will (siehe "schwampf"-kommentar im anderen
> Posting), aber ich bin mir nicht sicher, ob das nun in deinem Fall
> relevant ist. Wenn ich ein tar-file per netcat über's LAN schicke,
> würde ich lieber beim Einpacken schon filtern, und nicht erst beim
> Auspacken. Außer natürlich, ich habe dich missverstanden.
wie im anderen posting geschrieben, ich habe immer nur das ganze archiv
entpackt.
Willi Mann
> das aussehen der bytes hï¿œngt aber vom encoding ab. und ich bin sicher,
> dass das quellsystem iso-8859-1 und das zielsystem utf8 verwendet. meine
> auch dadurch das es bei mir funktioniert hat. convmv dï¿œrfte die filenames
> (byte-folgen) vom filesystem ï¿œndern, da es unabhï¿œngig von LANG variablen
> funktionierte. des weiteren vermute ich, dass es eine kerneleinstellung
> ich aber leider noch nichts gefunden.
Nein, es ist definitv keine Kerneleinstellung. Der Kernel sieht wirklich nur
eine Folge von Bytes. Was du dann siehst, hï¿œngt von deinen
Umgebungsvariablen bzw. anderen Encodingeinstellungen ab, und zwar denen
deines Terminalemulators (ls und tar arbeiten wirklich nur auf einer Folge
von Bytes).
convmv existiert gerade deshalb, weil der Kernel nur eine Folge von Bytes
sieht. Wenn diese Folge vor convmv iso-8859-1 war und nachher utf8, dann ist
es aus Kernelsicht einfach eine andere Folge. Die Kodierung ist dem Kernel
egal.
ntfs und vfat sind Spezialfï¿œlle, weil wahrscheinlich die Specification das
Encoding vorschreibt. Mit Hilfe der charset-Optionen kannst du es dann auf
dein gewï¿œnschtes Encodung umbiegen. Vor allem wï¿œre es ja schwierig, sonst in
einer iso-8859-1 Linux Umgebung auf ein utf codiertes nfts oder vfat
zuzugreifen.
>> Im tar-file sind also die originalen bytes gespeichert, und
>> wenn die am neuen, utf-8 basierten system entpackt werden,
>> gibt es ein paar mï¿œglichkeiten:
>> 1) das entpacker-prog schreibt die bytes der dateinamen
>> 1:1 ins filesystem, dann klappt zwar das entpacken,
>> aber die dateinamen erscheinen in dateimanagern (das
>> inkludiert auch "ls" :-) falsch.
>
> ich vermute, dass genau das stattgefunden hat. dieses vorgehen erachte ich
> als gefï¿œhrlich, da die bytefolgen in einem anderen encoding durchaus
> illegale zeichen beinhalten kï¿œnnen.
Naja, unter Linux kannst du ja auch Dateinamen mit Zeilenumbruch anlegen.
Vor allem wï¿œre es problematisch, wenn du ein Backup eines Home-
Verzeichnisses machst, dessen Benutzer jeder andere Encodingeinstellungen
hat. tar muss daher die Dateinamen als Bytefolge betrachten.
>> 2) das entpacker-programm erkennt die - gemￜￜ versuchter utf-8
>> interpretation falschen - bytes, und konvertiert sie
>> intern nach utf-8
>
> naja, dazu ist es notwendig, das encoding im tar file zu kennen. gefragt
> wurde ich danach nicht, und ich glaube nicht dass es erkannt/geschï¿œtzt
> wird.
So ist es.
Bleibt allerdings die Frage, warum bei dir Dateien nicht mehr sichtbar
waren. Das darf nicht passieren.
Wenn du testen willst, dann kannst du folgendes in einem Verzeichnis
probieren, indem du Dateien vermisst:
for i in *; do echo datei; done | wc -l
Die Ausgabe gibt die tatsï¿œchliche Anzahl aller Dateien im Verzeichnis an,
mit Ausnahme aller, die mit einem Punkt beginnen (versteckte Dateien).
WM
Jan C. Faerber
wrote:
> das aussehen der bytes hängt aber vom encoding ab. und ich bin sicher, dass
> das quellsystem iso-8859-1 und das zielsystem utf8 verwendet. meine annahme
> wird auf jeden fall bestätigt durch die existenz von convmv und auch dadurch
> das es bei mir funktioniert hat. convmv dürfte die filenames (byte-folgen)
> vom filesystem ändern, da es unabhängig von LANG variablen funktionierte.
> des weiteren vermute ich, dass es eine kerneleinstellung ist, in welchem
> encoding filenames gespeichert werden müssen, dazu habe ich aber leider noch
> nichts gefunden.
Hab soetwas auch von Suse auf Debian mittels fish:// gemacht.
Hab das selbe Problem: Die Umlaute werden umgewandelt in schwarze
Karos mit weißen Fragezeichen drinnen. Schätz das Beste wird sein,
zuvor einfach alle Umlaute zu verdammen bzw. umzuwandeln in ae, ue, oe
usw.
David Wührer
> Wenn du testen willst, dann kannst du folgendes in einem Verzeichnis
> probieren, indem du Dateien vermisst:
>
> for i in *; do echo datei; done | wc -l
>
> mit Ausnahme aller, die mit einem Punkt beginnen (versteckte Dateien).
ls -1A | wc -l
Alle Dateien einschließlich jener mit Punkt davor, mit Ausnahme von . und ..
(aktülles Verzeichnis und Parent-Verzeichnis.)
Willi Mann
>> for i in *; do echo datei; done | wc -l
>>
>> mit Ausnahme aller, die mit einem Punkt beginnen (versteckte Dateien).
>
> ls -1A | wc -l
>
> .. (aktï¿œlles Verzeichnis und Parent-Verzeichnis.)
Bist du sicher, dass das auch das gewï¿œnschte Ergebnis liefert, wenn jemand
eine Datei mit Zeilenumbruch im Dateisystem hat?
Ja, ich weiￜ, dass das (Zeilenumbruch im Dateinamen) grober Unfug ist, nur
wenn ich es oben schon erwï¿œhne, dann kann ich dann kein Kommando
inkludieren, das vielleicht ein nicht ganz richtiges Ergebnis liefert.
WM
Andreas Leitgeb
Auf einem iso-8859-1 system "sys1": dann stehen im Filesystem für den
Namen die bytes (in hex) 61 E4.
Auf einem utf-8 system "sys2": dann stehen für so eine Datei im filesystem
die bytes 61 C3 A4.
Wenn du nun auf sys1 ein tar-file anlegst, stehen im tarfile die bytes
61 E4, und wenn du das auf sys2 entpackst, wird dort als namen das dort
unpassende 61 E4 angelegt. Aus sicht von tar und dem fs auf sys2 ist
die Sache damit korrekt erledigt, aber wenn du z.b. "ls" drauf machst,
siehst du Schmierzeichen statt der umlaute.
Wenn nun das (auf sys1 erzeugte) tarfile ein directory "aä" und darin
eine datei gleichen Namens enthält. (also kompletter pfad in bytes:
61 E4 2F 61 E4), dann wird beim entpacken auf sys2 eben ein directory
und darin eine Datei angelegt, die beide einen namen haben, der auf
sys2 von den meisten tools flasch angezeigt wird.
Tools wie convmv benennen dann z.b. das directory von "61 E4" auf
"61 C3 A4" um, und in weiterer Folge den Pfad zur Datei von nun
"61 C3 A4 2F 61 E4" nach "61 C3 A4 2F 61 C3 A4" (das vor dem
schrägstrich 2F wurde ja schon gerade vorhin umbenannt)
Jürgen Richtsfeld <juergen.r...@gmx.at> wrote:
> ich vermute, dass genau das stattgefunden hat. dieses vorgehen erachte ich
> als gefährlich, da die bytefolgen in einem anderen encoding durchaus
> illegale zeichen beinhalten können.
Was ist "illegal"?
Im Prinzip hast eigentlich recht, da z.B. ein ucs-2 encoding tatsächlich
sehr schlecht wäre wegen der \0-bytes. Aber bei utf-8 ist das kein Thema.
In einem utf-8 system können auch Dateinamen existieren, die nicht
korrekt utf-8 sind.
> wie im anderen posting geschrieben, ich habe immer nur das ganze archiv
> entpackt.
Ok, jetzt weiss ichs. Damit ist mal ein Wust an anderen Fehlerquellen
ausgeschlossen.
Letztlich bleibt die Frage, warum bei dir Dateien nach dem Auspacken
fehlen. Das ist durch obige Theorie nicht wirklich geklärt. Probiere
mal, statt tar x... ein tar t... und pipe es durch hexdump.
Und dann mach ein find . | hexdump in dem Verz, wohin du ausgepackt
hast, und vergleiche es mit der obigen tar t...|hexdump ausgabe.
Bei ntfs/vfat unter unix schaut es genauso aus, nur ist dann noch
ein weiterer encoding-wechsel nachgeschaltet, was in manchen fällen
genau das richtige tut, und in anderen fällen das chaos noch verschlimmert:
Angenommen, ntfs ist mit charset iso-8859-1 gemountet, und es wird
auf sys1 (dem mit iso-8859-1) wieder ein "aä" angelegt, dann wird auf
fs-ebene die folge "61 E4" übergeben, was dann innerhalb des fs-treibers
in ucs-2 konvertiert wird: 00 61 00 E4 (modulo endianess).
Wird dieses filesystem (z.B. wechselplatte, usbstick) dann auf sys2 mit
charset=utf-8 gemountet, dann sieht unix als dateiname "61 C3 A4".
Wird da nun eine datei mit "61 E4" angelegt, kann es sein, dass im fs-
treiber dann die interne utf-8 -> ucs-2 konvertierung fehlschlägt, und die
Datei entweder wirklich nicht angelegt wird, oder halt als "a?" angelegt
wird.
Aber wenn ich mich recht erinnere, hast du ja geschrieben, dass du xfs
verwendest, also ist das eher nicht dein Szenario. Vielleicht irr ich mich
ja auch, und du hast das tarfile in ein ntfs/vfat entpackt, das würde dann
so manches erklären, bzgl dem geschilderten Auspack-verhalten.
David Wührer
> Bist du sicher, dass das auch das gewünschte Ergebnis liefert, wenn jemand
> eine Datei mit Zeilenumbruch im Dateisystem hat?
David Wührer
> Nehmen wir mal an, wir hätten eine Datei namens "aä":
> Auf einem iso-8859-1 system "sys1": dann stehen im Filesystem für den
> Namen die bytes (in hex) 61 E4.
> Auf einem utf-8 system "sys2": dann stehen für so eine Datei im filesystem
> die bytes 61 C3 A4.
[...]
> Tools wie convmv benennen dann z.b. das directory von "61 E4" auf
> "61 C3 A4" um, und in weiterer Folge den Pfad zur Datei von nun
> "61 C3 A4 2F 61 E4" nach "61 C3 A4 2F 61 C3 A4" (das vor dem
> schrägstrich 2F wurde ja schon gerade vorhin umbenannt)
Aber da das aus einem Tar-Ball entpackt wurde, wurde anscheinend die Datei
"aä/aä" nicht als solche angelegt, sondern als
61 E4 F2 61 E4 00
Wobei ich nicht weiß, welches Zeichen e4 f2 in UTF-8 ist, aber ich vermute,
es ist kein Schrägstrich.
Willi Mann
> Willi Mann wrote:
>> Bist du sicher, dass das auch das gewï¿œnschte Ergebnis liefert, wenn
>> jemand eine Datei mit Zeilenumbruch im Dateisystem hat?
> Bei mir schon.
$ mkdir test
$ cd test/
$ touch a
$ touch b
$ echo -en "t\nT" | xargs -0 touch
$ ls -lA | wc -l
5
Also bei mir nicht. Erstens gibt es bei mir eine zusï¿œtzliche Zeile fï¿œr
"insgesamt 0", zweitens zï¿œhlt er die Datei mit dem Zeilenumbruch zweimal.
Sieht man durch
$ ls -lA | cat
Und das ist nicht "useless use of cat", denn damit gibt ls nicht auf ein
Terminal aus, womit ls control characters nicht unterdrï¿œckt. Gibt auch eine
explizite Option dafï¿œr.
WM
Willi Mann
> Aber da das aus einem Tar-Ball entpackt wurde, wurde anscheinend die Datei
>
> 61 E4 F2 61 E4 00
Du meinst wohl 2F. Willst du mit dem 00 irgendetwas andeuten?
> Wobei ich nicht weiￜ, welches Zeichen e4 f2 in UTF-8 ist, aber ich
> vermute, es ist kein Schrï¿œgstrich.
Wieso ist das relevant? 2f ist Schrï¿œgstrich, aber es erklï¿œrt nicht, wohin
die Dateien verschwunden sind. Vor allem da der OP sagte, dass die
Verzeichnisse existierten, aber leer waren.
Interessant wï¿œre, wie der OP versucht hat, den Inhalt der Verzeichnisse
anzuzeigen.
WM
Jürgen Richtsfeld
> David Wührer wrote:
>> Aber da das aus einem Tar-Ball entpackt wurde, wurde anscheinend die
>> Datei "aä/aä" nicht als solche angelegt, sondern als
>>
>> 61 E4 F2 61 E4 00
>
> Du meinst wohl 2F. Willst du mit dem 00 irgendetwas andeuten?
>
>> Wobei ich nicht weiß, welches Zeichen e4 f2 in UTF-8 ist, aber ich
>> vermute, es ist kein Schrägstrich.
>
> Wieso ist das relevant? 2f ist Schrägstrich, aber es erklärt nicht, wohin
> die Dateien verschwunden sind. Vor allem da der OP sagte, dass die
> Verzeichnisse existierten, aber leer waren.
>
> Interessant wäre, wie der OP versucht hat, den Inhalt der Verzeichnisse
> anzuzeigen.
aus dem tar? das hab ich nicht probiert, da ich auf sys1 das tar in ein nc
gepiped habe, und auf sys2 vom nc ins tar gepiped und sofort extracted.
ich werde frühestens am wochenende soche sachen noch versuchen, danach ist
sys1 weg. ich denke aber, das ich das problem mit einer kleinen vm
nachstellen werde.
>
> WM
Willi Mann
>> Interessant wï¿œre, wie der OP versucht hat, den Inhalt der Verzeichnisse
>> anzuzeigen.
>
> aus dem tar? das hab ich nicht probiert, da ich auf sys1 das tar in ein nc
> gepiped habe, und auf sys2 vom nc ins tar gepiped und sofort extracted.
Ich meinte, wie hast du am Zielrechner nach dem Entpacken festgestellt, dass
die Verzeichnisse leer waren? Unter Umstï¿œnden hat sich ja nur das Programm
(z.B. ein Datei Browser) geweigert, die Dateinamen anzuzeigen. Auch ls kann
einen in die Irre fï¿œhren. Falls es ls war, wï¿œre der genaue Befehl sehr
interessant.
WM
Jürgen Richtsfeld
>
>>> Interessant wäre, wie der OP versucht hat, den Inhalt der Verzeichnisse
>>> anzuzeigen.
>>
>> aus dem tar? das hab ich nicht probiert, da ich auf sys1 das tar in ein
>> nc gepiped habe, und auf sys2 vom nc ins tar gepiped und sofort
>> extracted.
>
> Ich meinte, wie hast du am Zielrechner nach dem Entpacken festgestellt,
> dass die Verzeichnisse leer waren? Unter Umständen hat sich ja nur das
> Programm (z.B. ein Datei Browser) geweigert, die Dateinamen anzuzeigen.
> Auch ls kann einen in die Irre führen. Falls es ls war, wäre der genaue
> Befehl sehr interessant.
genau kann ich das leider nicht mehr sagen, aber ich meine ich bin mit cd
und tab-completion ins dir gewechselt und hab dann einfach ls ausgeführt.
mit dem kde dolphin hab ich auch ins verzeichnis gesehn, da war es auch
leer.
>
> WM
Willi Mann
>> Ich meinte, wie hast du am Zielrechner nach dem Entpacken festgestellt,
>> Programm (z.B. ein Datei Browser) geweigert, die Dateinamen anzuzeigen.
>> Befehl sehr interessant.
>
> genau kann ich das leider nicht mehr sagen, aber ich meine ich bin mit cd
> mit dem kde dolphin hab ich auch ins verzeichnis gesehn, da war es auch
> leer.
Die erste Variante ist jedenfalls nicht anfï¿œllig fï¿œr gar nichts anzeigen,
wenn doch etwas da ist. Bei dolphin weiￜ ich es nicht.
Falls du probieren willst, dem Fehler auf den Grund zu gehen, du kï¿œnntest
das, was du mit netcat ï¿œbers Netz schickst, vorher mit tee abfangen, also in
etwa
tar cvf - dir | tee test.tar | netcat ...
und dir dann den Inhalt des tar files (mit tar tf) anschauen. Wenn die
Dateien da sind, aber wieder am Zielsystem nicht angelegt werden, kannst du
das Quellsystem als Ursache ausschlieï¿œen. Das mit dem tee kannst du
natï¿œrlich auch am Zielsystem machen.
Wenn die Dateien dann im tar file am Zielsystem vorhanden sind, aber nicht
angelegt wurden, dann hast du wohl einen Bug entdeckt. Wenn sie im tar am
Zielsystem im Gegensatz zum Quellsystem nicht vorhanden sind, gab es wohl
ein Problem bei der ï¿œbertragung.
WM
David Wührer
> David Wührer wrote:
>
>> Willi Mann wrote:
>>> Bist du sicher, dass das auch das gewünschte Ergebnis liefert, wenn
>>> jemand eine Datei mit Zeilenumbruch im Dateisystem hat?
>> Bei mir schon.
>
> $ mkdir test
> $ cd test/
> $ touch a
> $ touch b
> $ echo -en "t\nT" | xargs -0 touch
> $ ls -lA | wc -l
> 5
>
> Also bei mir nicht.
Versuch, das l durch eine 1 zu ersetzen, vielleicht gehts dann.
David Wührer
> David Wührer wrote:
>> Aber da das aus einem Tar-Ball entpackt wurde, wurde anscheinend die
>>
>> 61 E4 F2 61 E4 00
>
> Du meinst wohl 2F. Willst du mit dem 00 irgendetwas andeuten?
Ja, 2F, tut mir leid.
0xE4 > 0x7f, daher nicht ASCII, und in UTF-8 bedeutet das ein Zeichen mit
mehr als einem Byte.
Deshalb nahm ich an, dass das folgenden Byte auch nicht als Schrägstrich
interpretiert würde.
Das wird es aber, weil 0x2f < 0x80.
Die angelegte Datei müsste also als "a�/a�" angezeigt werden.
Das erklärt also nicht, warum Verzeichnisse leer waren.
Tut mir leid.
Bernd Petrovitsch
> Willi Mann wrote:
>> David Wührer wrote:
>>> Aber da das aus einem Tar-Ball entpackt wurde, wurde anscheinend die
>>> Datei "aä/aä" nicht als solche angelegt, sondern als
>>>
>>> 61 E4 F2 61 E4 00
>>
>> Du meinst wohl 2F. Willst du mit dem 00 irgendetwas andeuten?
>
> Ja, 2F, tut mir leid.
>
> 0xE4 > 0x7f, daher nicht ASCII, und in UTF-8 bedeutet das ein Zeichen mit
> mehr als einem Byte.
interpretiert - und nicht nur da Attay of Bytes nimmt und mal open(2) damit
aufruft?!
`strace -vvv -s 1024` den `tar` Aufruf. Dann sollte man sehen, was da `tar`
wirklich macht (und wie die Filenamen wirklich ausschauen).
> Deshalb nahm ich an, dass das folgenden Byte auch nicht als Schrägstrich
> interpretiert würde.
Die Frage ist, *wer* das interpretiert bzw. in welchen Umständen?
> Das wird es aber, weil 0x2f < 0x80.
>
> Die angelegte Datei müsste also als "a�/a�" angezeigt werden.
> Das erklärt also nicht, warum Verzeichnisse leer waren.
>
> Tut mir leid.
`strace -vvv -s 1024` das `ls`. Dann sollte man sehen, welche Daten vom
Kernel wirklich rauskommen.
Alternativ mal `LANG=C LC_ALL=C' vor's `ls` packen bzw. andere Encodings
ausprobieren.
Bernd
--
"Designed for Windows" ist das Äquivalent zu Entwicklungsprinzipien
der russischen Armee: es muß so gut sein, daß es ein Bauerntrampel
nur schwer mutwillig kaputt kriegt. - Arnim Sommer
Willi Mann
> Versuch, das l durch eine 1 zu ersetzen, vielleicht gehts dann.
Nein, jetzt gibt's halt die Zeile "insgesamt 0" nicht mehr. Aber trotz 3
Dateien gibt es noch immer die Ausgabe 4.
Noch etwas: Wenn du in deinen Postings Behauptungen aufstellst, die leicht
zu ï¿œberprï¿œfen sind, dann sei doch bitte so freundlich, diese auch *vor* dem
Posten zu ï¿œberprï¿œfen.
WM
Bernd Petrovitsch
[...]
>> Versuch, das l durch eine 1 zu ersetzen, vielleicht gehts dann.
"Zeilenende" unterscheiden.
> Nein, jetzt gibt's halt die Zeile "insgesamt 0" nicht mehr. Aber trotz 3
> Dateien gibt es noch immer die Ausgabe 4.
>
> Noch etwas: Wenn du in deinen Postings Behauptungen aufstellst, die leicht
> zu überprüfen sind, dann sei doch bitte so freundlich, diese auch *vor*
> dem Posten zu überprüfen.
ACK.
Schon eher sollte
---- snip ----
find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" | wc -l
---- snip ----
funktionieren (mit einem GNU-find - k.A. ob ur-alt BSD- u.ä. `find`s -
maxdepth hatten/haben).
David Wührer
> David Wührer wrote:
>> 0xE4 > 0x7f, daher nicht ASCII, und in UTF-8 bedeutet das ein Zeichen mit
>> mehr als einem Byte.
> Und Du bist ganz sicher, daß das `tar` (welches genau?) da tatsächlich
> UTF-8 interpretiert - und nicht nur da Attay of Bytes nimmt und mal
> open(2) damit aufruft?!
In dem Fall wäre das auch irrelevant, weil es sowieso keine gültige UTF-8-
Sequenz ist. 0x2f ist also in jedem Fall ein Schrägstrich.
(Nicht bei UTF-16, aber da wären wohl die meisten Dateinamen einfach leer,
also die entsprechenden Dateien würden gar nicht erst angelegt.)
> Alternativ mal `LANG=C LC_ALL=C' vor's `ls` packen bzw. andere Encodings
> ausprobieren.
Für ls macht das jedenfalls einen Unterschied.
Wenn LANG=C, zeigt ls ein ä als ?? .
Ein ä in Latin-1 zeigt es als ?, egal ob C oder UTF-8.
Warum das mit tar für Jürgen nicht funktioniert hat, bleibt mir rätselhaft.
Das mit dem strace habe ich auch probiert. GNU/tar 1.22
Tatsächlich sehe ich da:
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
Willi Mann
> ---- snip ----
> find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" | wc -l
> ---- snip ----
> maxdepth hatten/haben).
Leider nein, hat das gleiche Problem wie ls: Ohne die Pipe wird der
Zeilenumbruch durch ? darstellt, mit Pipe wird er im Original ï¿œbergeben:
$ DIRECTORY=.
$ find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" | wc -l
4
$ find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY"
./b
./a
./t?T
$ find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" | cat
./b
./a
./t
T
WM
Andreas Leitgeb
> Warum das mit tar für Jürgen nicht funktioniert hat, bleibt mir rätselhaft.
Und solange er uns keinen Auszug seines strace-log zukommen lässt,
wird sich an dem Rätsel nicht so bald was klären.
Habe gerade mit ein paar tricks so ein tarfile hergestellt mit
iso-8859-1 umlauten drin, und dann ohne tricks entpackt, und es
lief alles wie erwartet: es wurde das verzeichnis und die datei
mit ihren iso-8859-1 namen exakt ausgepackt.
Es würde schon helfen, wenn uns Jürgen mal den exakten Namen
seiner umlaut-Verzeichnisse oder Dateien sagt, und wenn er
nochmals kontrolliert, ob das zielverzeichnis nicht vielleicht
doch auf einem gemounteten MS-filesystem (vfat/ntfs) war.
Bernd Petrovitsch
> Bernd Petrovitsch wrote:
>> David Wührer wrote:
>>> 0xE4 > 0x7f, daher nicht ASCII, und in UTF-8 bedeutet das ein Zeichen
>>> mit mehr als einem Byte.
>> Und Du bist ganz sicher, daß das `tar` (welches genau?) da tatsächlich
>> UTF-8 interpretiert - und nicht nur da Attay of Bytes nimmt und mal
>> open(2) damit aufruft?!
> Nein, bin ich nicht.
> In dem Fall wäre das auch irrelevant, weil es sowieso keine gültige UTF-8-
> Sequenz ist. 0x2f ist also in jedem Fall ein Schrägstrich.
> (Nicht bei UTF-16, aber da wären wohl die meisten Dateinamen einfach leer,
> also die entsprechenden Dateien würden gar nicht erst angelegt.)
>
>> Alternativ mal `LANG=C LC_ALL=C' vor's `ls` packen bzw. andere Encodings
>> ausprobieren.
> Für ls macht das jedenfalls einen Unterschied.
> Wenn LANG=C, zeigt ls ein ä als ?? .
Dann ist es wohl UTF-8 kodiert (weil 2 Byte).
> Ein ä in Latin-1 zeigt es als ?, egal ob C oder UTF-8.
Dann ist es wohl Latin-1 kodiert (weil 1 Byte).
> Warum das mit tar für Jürgen nicht funktioniert hat, bleibt mir
> rätselhaft.
Yup.
> Das mit dem strace habe ich auch probiert. GNU/tar 1.22
> Tatsächlich sehe ich da:
> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
Das (GNU-)`ls` i18n't und l10n't ist, ist ja unbestritten. Aber es müßte
noch jede Menge andere open(2) und read(2) geben.
Grrrml, `strace -v -egetdents ls -1` liefert genau die Liste aller
Filenamen, die der Kernel liefert.
Bernd Petrovitsch
>> Schon eher sollte
>> ---- snip ----
>> find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" | wc -l
>> ---- snip ----
>> funktionieren (mit einem GNU-find - k.A. ob ur-alt BSD- u.ä. `find`s -
>> maxdepth hatten/haben).
>
> Leider nein, hat das gleiche Problem wie ls: Ohne die Pipe wird der
> Zeilenumbruch durch ? darstellt, mit Pipe wird er im Original übergeben:
>
> $ DIRECTORY=.
> $ find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" | wc -l
> 4
> $ find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY"
> ./b
> ./a
> ./t?T
> $ find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" | cat
> ./b
> ./a
> ./t
> T
ACK, oOoops, sorry. Oh wie peinlich. Selber thinko wie bei `ls | wc`.
---- snip ----
find $DIRECTORY -maxdepth 1 ! -name "$DIRECTORY" -printf "\n" | wc -l
---- snip ----
sollte es tun. Da kriegen wir die Filenamen weg (die uns eh nicht
interessieren).
Jürgen Richtsfeld
> Es würde schon helfen, wenn uns Jürgen mal den exakten Namen
> seiner umlaut-Verzeichnisse oder Dateien sagt, und wenn er
> nochmals kontrolliert, ob das zielverzeichnis nicht vielleicht
> doch auf einem gemounteten MS-filesystem (vfat/ntfs) war.
die verzeichnisse enthalten einfach deutsche umlaute und blanks.
das quellfilesystem ist xfs, das zielfilesystem ext4.
ich werde mal zusehn, dass ich so einen strace lauf mache.
jürgen
David Wührer
>> Versuch, das l durch eine 1 zu ersetzen, vielleicht gehts dann.
>
> Nein, jetzt gibt's halt die Zeile "insgesamt 0" nicht mehr. Aber trotz 3
> Dateien gibt es noch immer die Ausgabe 4.
>
> Noch etwas: Wenn du in deinen Postings Behauptungen aufstellst, die leicht
> zu überprüfen sind, dann sei doch bitte so freundlich, diese auch *vor*
> dem Posten zu überprüfen.
Das habe ich, und bei mir hat es funktioniert.
David Wührer
> Das habe ich, und bei mir hat es funktioniert.
David Wührer
> David Wührer wrote:
>> Wenn LANG=C, zeigt ls ein ä als ?? .
> Dann ist es wohl UTF-8 kodiert (weil 2 Byte).
>> Ein ä in Latin-1 zeigt es als ?, egal ob C oder UTF-8.
> Dann ist es wohl Latin-1 kodiert (weil 1 Byte).
>> Das mit dem strace habe ich auch probiert. GNU/tar 1.22
>> Tatsächlich sehe ich da:
>> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
> Das (GNU-)`ls` i18n't und l10n't ist, ist ja unbestritten. Aber es müßte
> noch jede Menge andere open(2) und read(2) geben.
Den strace habe ich mit einem tar xf gemacht.
Und ja, das gibt es noch viele weitere, aber das schien der einzige zu sein,
der mit l10n zu tun hat.
Version ist GNU tar 1.22
Bernd Petrovitsch
Encoding besser raten zu können.
> Version ist GNU tar 1.22
Bernd
Andreas Leitgeb
> Andreas Leitgeb wrote:
>> Es würde schon helfen, wenn uns Jürgen mal den exakten Namen
>> seiner umlaut-Verzeichnisse oder Dateien sagt, und wenn er
>> nochmals kontrolliert, ob das zielverzeichnis nicht vielleicht
>> doch auf einem gemounteten MS-filesystem (vfat/ntfs) war.
> die verzeichnisse enthalten einfach deutsche umlaute und blanks.
Die Frage war deswegen, weil wenn die Umlaute nur einzeln im Namen
auftauchen, können viele Tools das irgendwie auto-konvertieren, aber
wenn z.B. ein Umlaut und ein scharfes ß hintereinander kommen, dann
besteht zumindest die Möglichkeit, dass größerer Unfug passiert,
weil die zusammen dann vielleicht doch ein gültiges utf-8 Zeichen
ergeben, was auch immer für eins.
Theoretisch sollte es ja komplett egal sein, aber praktisch...
> das quellfilesystem ist xfs, das zielfilesystem ext4.
> ich werde mal zusehn, dass ich so einen strace lauf mache.
gut.
Bernd Petrovitsch
> Jürgen Richtsfeld <juergen.r...@gmx.at> wrote:
>> Andreas Leitgeb wrote:
>>> Es würde schon helfen, wenn uns Jürgen mal den exakten Namen
>>> seiner umlaut-Verzeichnisse oder Dateien sagt, und wenn er
>>> nochmals kontrolliert, ob das zielverzeichnis nicht vielleicht
>>> doch auf einem gemounteten MS-filesystem (vfat/ntfs) war.
>> die verzeichnisse enthalten einfach deutsche umlaute und blanks.
sehr untechnisch, weil mehrdeutig.
> Die Frage war deswegen, weil wenn die Umlaute nur einzeln im Namen
> auftauchen, können viele Tools das irgendwie auto-konvertieren, aber
> wenn z.B. ein Umlaut und ein scharfes ß hintereinander kommen, dann
> besteht zumindest die Möglichkeit, dass größerer Unfug passiert,
> weil die zusammen dann vielleicht doch ein gültiges utf-8 Zeichen
> ergeben, was auch immer für eins.
Spaßig wird's mit derartigen Heuristiken, wenn das Driectory UTF-8-kodiert
ist und der Filename ISO-8859-15 (und jeweils beide einen Umlaut haben).
> Theoretisch sollte es ja komplett egal sein, aber praktisch...
... wird das eine oder andere Tool vielleicht auch diesbezüglich noch buggy
sein.
>> das quellfilesystem ist xfs, das zielfilesystem ext4.
>> ich werde mal zusehn, dass ich so einen strace lauf mache.
>
> gut.
ACK.
David Wührer
> Naja, die Idee war, die *Filenamen* im strace-Output zu sehen, um das
> Encoding besser raten zu können.
open("a\344", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 4
Bei UTF-8 so:
open("a\303\244", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = 4
Nichts unerwartetes.
Jürgen Richtsfeld
sparen.
ich hatte von dem zielsystem eine ssh connection zum quellsystem aus einem
kde terminal (konsole). bei soeben angelegten files funktionierte das ganze
- das hat mich verwirrt. alte files wurden auch in dem terminal falsch
angezeigt.
ein umstellen des character encodings (auf iso8859-15) im terminal hatte
dann zur folge, dass ein testweise angelegtes directory mit umlauten
"falsch" aussah, dafür die bestehenden umlaute richtig.
mit dem neuen encoding habe ich dann das tar über netcat erneut probiert -
und das test-directory und die darin enthaltenen files waren da.
auf jeden fall hat das umstellen des character encodings in der (kde)
konsole das verhalten verbessert - ich kann den fehler nicht mehr
nachstellen.
um noch offene fragen zu beantworten:
* in der ssh session zum sys1 mit character encoding iso8859-15 liefert
$ LANG=C LC_ALL=C ls
deutsche umlaute als ?
(ein ls liefert sie richtig (d.h. zeigt sie aus meiner sicht richtig an),
$ locale
LANG=en_US
LANGUAGE=en_AT:en_US:en_GB:en
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=
)
* auf sys1: $ strace tar cf ~/test.tar aaä/
...
lstat("aa\344", {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
open("aa\344", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4
...
ich denke, dass ich die ursache für das problem jetzt kenne, aber wie sieht
die lösung aus für:
* erzeuge backup mit tar auf system mit latin1 encoding
* restore daten von tar auf system mit utf8 encoding
muss man in dem fall mit convmv arbeiten, um die filenames der restaurierten
daten zu reparieren?
jürgen
Andreas Leitgeb
> auf jeden fall hat das umstellen des character encodings in der (kde)
> konsole das verhalten verbessert - ich kann den fehler nicht mehr
> nachstellen.
An der Darstellung kann sich ja viel ändern, aber auf die Existenz oder
nicht-Existenz der ausgepackten Dateien *darf* das eigentlich keine
Auswirkung gehabt haben.
> * erzeuge backup mit tar auf system mit latin1 encoding
> * restore daten von tar auf system mit utf8 encoding
> muss man in dem fall mit convmv arbeiten, um die filenames der restaurierten
> daten zu reparieren?
Ja, man muss.
Es wäre zwar denkbar, dass moderne Archiv-manager die Konvertierung
der Dateinamen als optionales extra-feature anbieten, aber zumindest
der von gnome scheint das nicht zu tun, und den von kde müsst ich
dazu erst installieren.
PS: als ich meine systeme von iso8859-1 nach utf-8 konvertierte (im
Jahre Schnee^W 2007, wimre), hab ich mir damals ein Umbenenn-script
selber in tcl geschrieben, da ich convmv damals nicht kannte. (Habs
seither noch nicht verglichen, drum kann ich nicht sagen, ob mein
script oder convmv "besser" war.)
Falls es dich interessiert:
<http://www.logic.at/people/avl/stuff/convertNamesToUtf8.tcl>
Andreas Leitgeb
> Jürgen Richtsfeld <juergen.r...@gmx.at> wrote:
>> auf jeden fall hat das umstellen des character encodings in der (kde)
>> konsole das verhalten verbessert - ich kann den fehler nicht mehr
>> nachstellen.
>
> An der Darstellung kann sich ja viel ändern, aber auf die Existenz oder
> nicht-Existenz der ausgepackten Dateien *darf* das eigentlich keine
> Auswirkung gehabt haben.
Und da hab ich schon wieder schneller getippt als gedacht.
Wenn das Einpacken in einer Shell erfolgte, wo du am Rechner
"sys2" saßest, und per ssh auf "sys1" eingeloggt warst, und wenn
du dann in der remote-session auf "sys1" beim *Einpacken* den
Verzeichnisnamen mit umlaut angegeben hast, ja, dann waren jene
Dateien wohl letztlich nie im (ge-netcat-eten) tar-"stream" drin.
Abhilfe dafür:
Entweder das Einpacken direkt am "sys1" erledigen, oder:
auf "sys2" den "screen" starten, darin dann <Ctrl-A>:utf8<Return>
tippen, und darin dann auf "sys1" ssh-en, dann sieht "sys1" die von
ihm erwarteten iso-8859-1 umlaute in der Kommando-zeile, und mit
denen erkennt er dann auch die Datei wieder, die es einzupacken
gilt.
Willi Mann
> Und da hab ich schon wieder schneller getippt als gedacht.
>
> Wenn das Einpacken in einer Shell erfolgte, wo du am Rechner
> du dann in der remote-session auf "sys1" beim *Einpacken* den
> Verzeichnisnamen mit umlaut angegeben hast, ja, dann waren jene
> Dateien wohl letztlich nie im (ge-netcat-eten) tar-"stream" drin.
Aber das kann doch nur bei expliziter Angabe des spï¿œter fehlenden
Verzeichnisnamens (bzw. Dateinamens) schlagend werden. Jï¿œrgen Richtsfeld
sagte aber, dass Verzeichnisse am Zielsystem angelegt wurden, die keine
Datei beinhalteten. Damit das also zum Problem wird, mï¿œsste er alle Dateien
einzeln angegeben haben - und das wird er wohl nicht gemacht haben.
Wenn er nï¿œmlich nur nicht existente Verzeichnisse angegeben hï¿œtte, dann
wï¿œren schon die gar nicht im tar angelegt worden (zumindest GNU tar).
WM
Andreas Leitgeb
>> Und da hab ich schon wieder schneller getippt als gedacht.
>> Wenn das Einpacken in einer Shell erfolgte, wo du am Rechner
>> du dann in der remote-session auf "sys1" beim *Einpacken* den
>> Verzeichnisnamen mit umlaut angegeben hast, ja, dann waren jene
>> Dateien wohl letztlich nie im (ge-netcat-eten) tar-"stream" drin.
> Verzeichnisnamens (bzw. Dateinamens) schlagend werden. Jürgen Richtsfeld
> wären schon die gar nicht im tar angelegt worden (zumindest GNU tar).
Ich suche immernoch krampfhaft nach Erklärungen für das geschilderte
Verhalten von tar. Kleine, der aktuellen Arbeitsthese widersprechende
Details werden da schon mal als "möglicherweise nur Messfehler" abgetan :-D
Willi Mann
> Ich suche immernoch krampfhaft nach Erklï¿œrungen fï¿œr das geschilderte
> Verhalten von tar. Kleine, der aktuellen Arbeitsthese widersprechende
> Details werden da schon mal als "mï¿œglicherweise nur Messfehler" abgetan
> :-D
ROTFL
Aber solange niemand eine vollstï¿œndige Anleitung zum Reproduzieren des
Fehlers gibt, werden wir auch weiterhin nur raten.
WM
Jürgen Richtsfeld
>
>> Und da hab ich schon wieder schneller getippt als gedacht.
>>
>> Wenn das Einpacken in einer Shell erfolgte, wo du am Rechner
>> "sys2" saßest, und per ssh auf "sys1" eingeloggt warst, und wenn
>> du dann in der remote-session auf "sys1" beim *Einpacken* den
>> Verzeichnisnamen mit umlaut angegeben hast, ja, dann waren jene
>> Dateien wohl letztlich nie im (ge-netcat-eten) tar-"stream" drin.
>
> Aber das kann doch nur bei expliziter Angabe des später fehlenden
> Verzeichnisnamens (bzw. Dateinamens) schlagend werden. Jürgen Richtsfeld
> sagte aber, dass Verzeichnisse am Zielsystem angelegt wurden, die keine
> Datei beinhalteten. Damit das also zum Problem wird, müsste er alle
> Dateien einzeln angegeben haben - und das wird er wohl nicht gemacht
> haben.
>
> Wenn er nämlich nur nicht existente Verzeichnisse angegeben hätte, dann
> wären schon die gar nicht im tar angelegt worden (zumindest GNU tar).
ich hab auf sys1 einfach ein
tar c blah | nc sys2 3000
wobei blah ein zu übertragendes verzeichnis ist (dessen name in allen fällen
nur character mit ascii < 128 hat),
und auf sys2 ein
nc -l 3000 | tar xv
gemacht.
beide befehle habe ich auf sys2 in einer kde konsole session getippt (auf
sys1 dann über ssh)
>
> WM
jürgen
Andreas Leitgeb
> ich hab auf sys1 einfach ein
> tar c blah | nc sys2 3000
> nc -l 3000 | tar xv
> gemacht.
Hab irgendwie den Überblick verloren.
Kannst du es(*) noch reproduzieren?
Interessiert es(*) überhaupt noch irgendwen?
("kein followup" gilt als "mich jedenfalls nicht" ;)
*: das unerwartete *nicht-Auspacken* bestimmter Dateien
aufgrund von encoding-Problemen der Dateinamen.
Jürgen Richtsfeld
> Jürgen Richtsfeld <juergen.r...@gmx.at> wrote:
>> ich hab auf sys1 einfach ein
>> tar c blah | nc sys2 3000
>> und auf sys2 ein
>> nc -l 3000 | tar xv
>> gemacht.
>
> Hab irgendwie den Überblick verloren.
> Kannst du es(*) noch reproduzieren?
nein - der pc mit dem ich das problem hatte wurde schon einem neuen
verwendungszweck zugeführt. wie in meinem letzten post geschrieben, hat es
dann mal funktioniert. falls es meine zeit aber erlaubt, werde ich nochmal
versuchen, ein altes debian als vm zu installieren, damit kann man es ev.
nochmal nachstellen probieren.
> Interessiert es(*) überhaupt noch irgendwen?
glaube nicht.
> ("kein followup" gilt als "mich jedenfalls nicht" ;)
>
> *: das unerwartete *nicht-Auspacken* bestimmter Dateien
> aufgrund von encoding-Problemen der Dateinamen.
danke für die rege teilnahme an dieser problemlösung!
jürgen