tar can't create

[ath0]

Zitat von Yamagi

Raten wir mal weiter: Sind vielleicht irgendwelche Dateisystem-Flags wie "schg" im Spiel?

Nein das Archiv enthält nur mails (im maildir format verwaltet von dovecot) einige configs die wie gesagt zu postfix, mysql, dovecot und apache22 (ich glaube das war alles) gehören. Zusätzlich sind noch webseiten in dem Paket. Es läst sich sonst alles entpacken und alle dateien in dem mailverzeichnis haben die selben Rechte auf dem Quellsystem (vmail:mail)und im Archiv(root:wheel) und nach dem Entpacken (root:wheel) wenn das ganze erfolgreich läuft wird beim entpacken von einem kleinen script das verzeichnis wieder mit den ursprünglichen Rechten bestückt (vmail:mail).
Eigentlich ist es nicht schlimm das die Datei jetzt fehlt (hoffe ich) da es nur eine Mail von mir ist, aber wissen würde ich schon gerne was da los ist.

[SeppoE]

Wie sieht es denn ohne -C aus? Weiß gerad nich, ob es Sinn macht, mit -P einzupacken und mit -C auszupacken.
Und -p nimmt ja auch die User-/Group ID mit, ggf. sollten die auf dem Zielsystem vorhanden sein und das Ziel das Setzen der Berechtigungen erlauben?

[ath0]

Auch ohne die Option "C" bekomme ich die Fehlermaldung. Ok "P" macht evtl. keinen Sinn mehr, aber auch ohne "P" bleibt die Meldung. User und Gruppe sind vorhanden sogar mit selber U und GID. Währen sie es nicht, würde das keinen unterschied machen, da alle entpackten Dateien User und Gruppe des entpackenden erhalten, da ich beim entpacken die Option "p" nicht nutze, um diesen Fehler auszuschließen. Wobei ich das langsam mal wieder ändern könnte, würde mir ne menge chmod bzw. chown Geschichten sparen

Ich würde das ganze für abgeschlossen halten, da es nur genau diese eine Datei betrifft und mein Mailserver sonst wieder, wie gewohnt, sauber läuft.
Ich hatte gedacht es gibt eine Möglichkeit tar "einfach" eine bessere Fehlerbeschreibung auszuspucken, ich wollte nicht 100 Leute damit belästigen.

Vielen Dank für eure Hilfe
ath0

[SeppoE]

Funxt denn
tar -v -xf -C /ziel/verzeichnis dateixyz.tar

irgendwie, oder andere Varianten? Weil in der man page steht
-C directory
--directory directory Change to directory before processing the remaining
arguments.

Interessiert ja für's Knobeln nicht, was genau in der Datei drinsteht

[Olodin]

Zitat von ath0

Ich hatte gedacht es gibt eine Möglichkeit tar "einfach" eine bessere Fehlerbeschreibung auszuspucken, ich wollte nicht 100 Leute damit belästigen.

Läuft denn ein "tar -t -f -v <file>" mit dieser Datei ohne Fehlermeldung durch?

[ath0]

Zitat von Olodin

Läuft denn ein "tar -t -f -v <file>" mit dieser Datei ohne Fehlermeldung durch?

nein er sagt

tar: Error opening archive: Failed to open '-v'

spaß bei seite,

tar -tf

läuft durch.

@SeppoE
Wenn ich

tar -v -xf -C /ziel/verzeichnis dateixyz.tar

ausführe bekomme ich auch

tar: Error opening archive: Failed to open '-C'

Wenn Ihr noch ne idee habt, ich hebe die Datei erstmal auf

[makenoob]

Hinter dem -f sollte immer der Dateiname folgen, daher auch die Fehlermeldungen.

Zitat von manpage

tar {-r | -u} -f archive-file [options] [files | directories]
...
-f file
Read the archive from or write the archive to the specified file.
The filename can be - for standard input or standard output. If
not specified, the default tape device will be used. (On
FreeBSD, the default tape device is /dev/sa0.)

[Daemotron]

Hast Du schon mal versucht, die Datei erst mit gunzip zu entpacken und dann tar drauf loszulassen? Kannst Du denn die Datei auf dem Quellsystem wieder entpacken?

Falls das "nackte" (unkomprimierte) Archiv immer noch Ärger bereitet, könntest Du mit grep mal den Bereich suchen, in dem sich die zickige Datei versteckt hält (der Dateiname steht ASCII-codiert im Header drin). Dann wären die 512 bytes interessant, die den Header für diese Datei bilden. Mit Hexdump und ein paar Kniffen lässt sich eventuell mit Gewalt die gesamte Datei da herauslösen (siehe http://en.wikipedia.org/wiki/Tar_%28file_format%29).