[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Datei wird nicht von tar gesichert



Am Dienstag, den 15.05.2012, 15:38 +0200 schrieb Stefan Baur:
> Hi Liste,
> 
> in meinem Homeverzeichnis liegt unter anderem auch eine Datei wie diese 
> hier:
>   ls -lh /home/meinbenutzeraccount/*.txt
> -rw-r--r-- 1 meinbenutzeraccount meinbenutzeraccount 288 May  8 15:04 
> /home/meinbenutzeraccount/C:\nppdf32Log\debuglog.txt
> 
> Dieser Mist kommt laut Google-Suche 
> (http://forums.mozillazine.org/viewtopic.php?p=11925323&sid=c2869da8c19da52032f04f07ac623dea#p11925323) 
> von einem Fehler in Version 9.5.1 des Adobe-Reader-Plugins.
> 
> Jeglicher Versuch, mein homedir mittels tar zu sichern, scheitert 
> seitdem, da das Skript, was ich dafür verwende, abbricht und eine 
> Alarm-E-Mail schickt, wenn tar an dieser Stelle Fehler wirft.
> 
> Alte Version:
> [...]
> find ./home ! -type s > filelist
> tar --no-recursion -T filelist -cf - | pbzip2 > /mnt/backup/$DATUM.tar.bz2
> [...]
> 
> Die Fehlermeldung lautet:
> tar: ./home/meinbenutzeraccount/C\:\nppdf32Log\\debuglog.txt: Cannot 
> stat: No such file or directory
> 
> Wie man sieht, ist das Escapen der Escape-Zeichen irgendwie kaputt (Und 
> um Rekursion zu verstehen, muss man... jaja).
> 
> Nun dachte ich, ich könnte dem so begegnen:
> 
> [...]
> find ./home ! -type s -print0 > filelist
> tar --no-recursion --null -T filelist -cf - | pbzip2 
>  >/mnt/backup/$DATUM.tar.bz2
> [...]
> 
> Aber leider ändert das rein gar nichts an der Fehlermeldung (auch wenn 
> es ansonsten sicher sauberer ist):
> tar: ./home/meinbenutzeraccount/C\:\nppdf32Log\\debuglog.txt: Cannot 
> stat: No such file or directory
> 
> Nun fand ich in der manpage von tar (aber nur in der englischsprachigen, 
> zu erreichen mit man -LC 1 tar):
> --no-unquote
>             do not unquote filenames read with -T
> 
> das habe ich dann so ausprobiert
> 
> [...]
> find ./home ! -type s -print0 > filelist
> tar --no-recursion --null -T filelist --no-unquote -cf - | pbzip2 
>  >/mnt/backup/$DATUM.tar.bz2
> [...]
> 
> und damit läuft das Teil wieder fehlerfrei durch. Aber mir ist nicht so 
> ganz klar, was ich mit "--no-unquote" genau anstelle und was das für 
> Seiteneffekte hat. "do not unquote filenames read with -T" ist eine 
> Erklärung, mit der ich an der Stelle allein nicht wirklich viel anfange.
> 
> Was genau geht da überhaupt schief?
> 
> tar meint ja, der Dateiname sei
> ./home/meinbenutzeraccount/C\:\nppdf32Log\\debuglog.txt
> dabei ist er
> ./home/meinbenutzeraccount/C:\nppdf32Log\debuglog.txt
> und richtig escapet wäre er
> ./home/meinbenutzeraccount/C:\\nppdf32Log\\debuglog.txt
> 
> Wieso "verrutscht" der Backslash beim C:?
> 
> Wer kann mir Erleuchtung verschaffen?

Interessanter Fehler.
Ich habe nun mal versucht herraus zu finden, welches Programm hier die
Namen escaped.

$ touch 'C:\nppdf32Log\debuglog.txt'
$ find . -maxdepth 1 -iname "C*"
./C:\nppdf32Log\debuglog.txt
find . -maxdepth 1 -iname "C*" > filelist
$ cat filelist 
./C:\nppdf32Log\debuglog.txt


Also find escaped nichts.
Nun versuche ich mal tar.

$ tar --no-recursion -T filelist -cjvf archiv.tar.bz2
tar: ./C\:\nppdf32Log\\debuglog.txt: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors

Wie es aussieht escaped tar das gelesene, aber falsch.

Bezüglich --unquote / --no-unquote :
tar liest die einzelnen Zeilen der Datei als Text (quoted string).
Der Text C:\nppdf32Log\debuglog.txt wird als 'C:\nppdf32Log
\debuglog.txt' eingelesen.
Genauso wie ich es mit touch gemacht habe.
Per Default arbeitet tar mit --unquote.
tar entfernt damit die quotes (Anführungszeichen), muß aber den String
dann nach Zeichen durchsuchen die escaped gehören.
Hier dürfte tar unter bestimmten Umständen Fehler machen.
Die Option --no-unquote weist tar an, die quoted strings so zu nehmen
wie sie sind. Da die Strings dadurch nicht escaped werden, tritt der
Fehler auch nicht auf.

$ tar --no-recursion -cjvf archiv.tar.bz2 'C:\nppdf32Log\debuglog.txt'  
tar: C\:\nppdf32Log\\debuglog.txt: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors

tar --no-recursion --no-unquote -cjvf archiv.tar.bz2 'C:\nppdf32Log\debuglog.txt'  
C:\\nppdf32Log\\debuglog.txt

Um das einzugrenzen habe ich ein paar Testfiles angelegt.

$ cat filelist 
./foo\bar
./foo bar
./foo :bar
./foo\:bar
./foo: bar
./foo:\bar
./foo:bar
./foo\ bar
./foo \bar

$ tar --no-recursion -T filelist -cjvf archiv.tar.bz2
tar: ./foo\bar: Cannot stat: No such file or directory
./foo bar
./foo :bar
./foo\\:bar
./foo: bar
tar: ./foo\:\bar: Cannot stat: No such file or directory
./foo:bar
./foo\\ bar
tar: ./foo \bar: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors

tar -tf archiv.tar.bz2 
./foo bar
./foo :bar
./foo\\:bar
./foo: bar
./foo:bar
./foo\\ bar

Es fehlen also 3 Dateien:
./foo\bar
./foo:\bar
./foo \bar
Bei den beiden letzten meckert tar, aber von der ersten Datei fehlt jede
Spur, sogar eine Meldung bleibt aus.
Der Selbe Test mit --no-unquote:

$ tar --no-recursion --no-unquote -T filelist -cjvf archiv.tar.bz2
./foo\\bar
./foo bar
./foo :bar
./foo\\:bar
./foo: bar
./foo:\\bar
./foo:bar
./foo\\ bar
./foo \\bar

$ tar -tf archiv.tar.bz2 
./foo\\bar
./foo bar
./foo :bar
./foo\\:bar
./foo: bar
./foo:\\bar
./foo:bar
./foo\\ bar
./foo \\bar

Hier sind alle Dateien vorhanden (obwohl tar den Backslash escaped
ausgibt).

Gefunden habe ich diesen Bug-Report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597577

Wie in diesem Bug-Report habe ich ebenfalls stat versucht:

$ stat -c %N 'C:\nppdf32Log\debuglog.txt' 
„C:\\nppdf32Log\\debuglog.txt“

stat escaped also richtig.
Ich denke das ist genug Material damit du dich an den Bug-Report
anhängen kannst.
Fürs erste ist der Workaround mit --no-unquote hilfreich.

-- 
mfG Sascha

Keine Nation gewinnt ein Urteil, als wenn sie über sich selbst 
urteilen kann. Zu diesem großen Vorteil gelangt sie aber sehr spät.
		-- Goethe, Maximen und Reflektionen, Nr. 259

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: