Mailinglist Archive: opensuse-de (1951 mails)
| < Previous | Next > |
Re: zip und lange Datenstroeme
- From: David Haller <david@xxxxxxxxxx>
- Date: Mon, 19 Dec 2005 03:10:40 +0100
- Message-id: <20051219021040.GA18206@xxxxxxxxxxxxxxxxxx>
Hallo,
Am Sun, 18 Dec 2005, Andre Tann schrieb:
>David Haller, Sonntag, 18. Dezember 2005 21:36:
>
>> 2. ist es kein Problem fuer gzip / bzip2:
>
>Danke, hab ich grad probiert, und geht.
*g* Ich hab grad Lust und erklaere dazu noch was: zip ist ein
"Windows" Packer, der Datei-orientiert arbeitet. D.h. er nimmt nen
Archiv-Namen und ein oder mehrere Dateinamen und packt diese in das
Archiv. compress, gzip und bzip2 sind "klassisch" und Stream-
orientiert, d.h. die schert es nicht _was_ sie da komprimieren.
Daher auch die Limitierung von compress/gzip/bzip2 auf einzelne
Dateien bzw. einen "stream"; das Archiv der "vielen" Dateien muss was
anderes machen, klassisch tar, wobei dann das tar gesamt komprimiert
wird, oder andersrum afio, das erst die Dateien komprimieren laesst
und dann die komprimierten Dateien zu einem Archiv zusammenpackt. BTW:
das Debian 'deb' Format ist (oder war) ein 'ar' Archiv, das (wie bei
afio) diverse (auch schon komprimierte) Dateien und ein paar
Zusatzinfos zu einer Datei zusammenpackt.
Als Umsteiger von Win* irritert das Verhalten der Unix-Tools erstmal, aber
schaut man sich mal die Arbeitsweise an wird einem klar, dass gerade die
Datei-orientierte Arbeisweise von zip einfach nicht zu Unix passt.
Und bzip2 komprimiert i.d.R. auch noch besser als zip (aber langsamer),
gzip AFAIK ungefaehr aehnlich.
Nochmal zur Verdeutlichung:
zip: komprimiert die Dateien(!, nicht bel. streams) mit einem der
zip-Algorithmen und packt sie in ein Archiv:
zip archive.zip *
afio: komprimiert die Dateien per compress/gzip/bzip2 und packt sie in
ein Archiv, aehnlich zu:
compress * && ar cr archive.a *.Z
gzip * && ar cr archive.a *.gz
bzip2 * && ar cr archive.a *.bz2
tar c[zj]: baut ein Archiv und komprimiert dieses anschliessend,
aehnlich zu:
ar cr archive.a * && compress archive.a
ar cr archive.a * && gzip archive.a
ar cr archive.a * && bzip2 archive.a
Mit dem Unterschied eben, dass compress/gzip/bzip2 im Gegensatz zu
'zip' generell "stream"-orientiert sind und sich somit wunderbar in
eine Pipe einbauen lassen. Dass man fuer die Ausgabe auf stdout ein
'-c' angeben muss ist IMO wohl nur der Praxis geschuldet.
AFAIR ist folgendes aus 'zip -h' ein Feature der Implementation fuer
Unix:
If zipfile and list are omitted, zip compresses stdin to stdout.
Die Win* Zips koennen das i.d.R. nicht, also sowas:
bla | zip | fasel
bzw.:
bla | zip - - | fasel
Das ist also wohl implementationsspezifisch und fuer "zip"-
Implementationen eher unueblich.
>[Dinge über ssh]
>> Man beachte das Quoting! Noch Fragen?
>
>Nee, eigentlich nicht... Quoting ist klar - was mir noch nicht so
>klar war, ist, daß mir ssh dasjenige auf stdout zurückgibt, was der
>entfernte Prozeß produziert. Aber könnte mal sehr praktisch sein.
Ist es! :)) SSH kann "netcat over ssh" ;)
BTW: alternativ kann man so z.B. tar ueber's Netz jagen:
==== eine Zeile, auf 192.168.0.2 laeuft ein Knoppix mit sshd ====
ssh root@xxxxxxxxxxx "( cd /mnt/hda1; tar cp --atime-preserve
--exclude=hiberfil.sys --exclude=pagefile.sys . ; ) " | tar xvp
--atime-preserve
====
Man beachte wiederum das Quoting (also was wo ausgefuehrt wird).
Wobei, AFAIR kann auch tar selber ueber's Netz, aber oben hab ich's
eben per SSH gemacht (auch wenn's nur ueber ein Crossover-Kabel war);
geraten muesste (ohne excludes):
ssh root@xxxxxxxxxxx \
"tar -cp --atime-preserve -f root@xxxxxxxxxxx:- /mnt/hda1"
das Aequivalent sein. Wobei man statt stdout ggfs. auch gleich nen
Dateinamen angeben koennen sollte:
ssh root@xxxxxxxxxxx \
"tar -cp --atime-preserve -f root@xxxxxxxxxxx:./foo.tar /mnt/hda1"
Wie das aber dann mit Zugriffsrechten usw. etc. pp. aussieht weiss ich
nicht, ich habe eben fuer obiges Backup die einfache Variante mittels
stdin/-out genommen, weil ich da nicht viel rumprobieren musste, denn
ich hatte den Laptop mit der IP .2 nur kurz zum reparieren da und
wollte mich nicht gross mit der u.a. ssh(d) Konfiguration hueben und
drueben (ein Knoppix auf dem WinXP Laptop) befassen.
-dnh
--
Bei uns sagt man, je nach dem wo man sich gerade aufhält,
entweder Scheißteil oder Drecksding und manchmal auch
Gehtschonwiedernichtdiescheiße dazu. -- U. Eckhardt ueber Notes
Am Sun, 18 Dec 2005, Andre Tann schrieb:
>David Haller, Sonntag, 18. Dezember 2005 21:36:
>
>> 2. ist es kein Problem fuer gzip / bzip2:
>
>Danke, hab ich grad probiert, und geht.
*g* Ich hab grad Lust und erklaere dazu noch was: zip ist ein
"Windows" Packer, der Datei-orientiert arbeitet. D.h. er nimmt nen
Archiv-Namen und ein oder mehrere Dateinamen und packt diese in das
Archiv. compress, gzip und bzip2 sind "klassisch" und Stream-
orientiert, d.h. die schert es nicht _was_ sie da komprimieren.
Daher auch die Limitierung von compress/gzip/bzip2 auf einzelne
Dateien bzw. einen "stream"; das Archiv der "vielen" Dateien muss was
anderes machen, klassisch tar, wobei dann das tar gesamt komprimiert
wird, oder andersrum afio, das erst die Dateien komprimieren laesst
und dann die komprimierten Dateien zu einem Archiv zusammenpackt. BTW:
das Debian 'deb' Format ist (oder war) ein 'ar' Archiv, das (wie bei
afio) diverse (auch schon komprimierte) Dateien und ein paar
Zusatzinfos zu einer Datei zusammenpackt.
Als Umsteiger von Win* irritert das Verhalten der Unix-Tools erstmal, aber
schaut man sich mal die Arbeitsweise an wird einem klar, dass gerade die
Datei-orientierte Arbeisweise von zip einfach nicht zu Unix passt.
Und bzip2 komprimiert i.d.R. auch noch besser als zip (aber langsamer),
gzip AFAIK ungefaehr aehnlich.
Nochmal zur Verdeutlichung:
zip: komprimiert die Dateien(!, nicht bel. streams) mit einem der
zip-Algorithmen und packt sie in ein Archiv:
zip archive.zip *
afio: komprimiert die Dateien per compress/gzip/bzip2 und packt sie in
ein Archiv, aehnlich zu:
compress * && ar cr archive.a *.Z
gzip * && ar cr archive.a *.gz
bzip2 * && ar cr archive.a *.bz2
tar c[zj]: baut ein Archiv und komprimiert dieses anschliessend,
aehnlich zu:
ar cr archive.a * && compress archive.a
ar cr archive.a * && gzip archive.a
ar cr archive.a * && bzip2 archive.a
Mit dem Unterschied eben, dass compress/gzip/bzip2 im Gegensatz zu
'zip' generell "stream"-orientiert sind und sich somit wunderbar in
eine Pipe einbauen lassen. Dass man fuer die Ausgabe auf stdout ein
'-c' angeben muss ist IMO wohl nur der Praxis geschuldet.
AFAIR ist folgendes aus 'zip -h' ein Feature der Implementation fuer
Unix:
If zipfile and list are omitted, zip compresses stdin to stdout.
Die Win* Zips koennen das i.d.R. nicht, also sowas:
bla | zip | fasel
bzw.:
bla | zip - - | fasel
Das ist also wohl implementationsspezifisch und fuer "zip"-
Implementationen eher unueblich.
>[Dinge über ssh]
>> Man beachte das Quoting! Noch Fragen?
>
>Nee, eigentlich nicht... Quoting ist klar - was mir noch nicht so
>klar war, ist, daß mir ssh dasjenige auf stdout zurückgibt, was der
>entfernte Prozeß produziert. Aber könnte mal sehr praktisch sein.
Ist es! :)) SSH kann "netcat over ssh" ;)
BTW: alternativ kann man so z.B. tar ueber's Netz jagen:
==== eine Zeile, auf 192.168.0.2 laeuft ein Knoppix mit sshd ====
ssh root@xxxxxxxxxxx "( cd /mnt/hda1; tar cp --atime-preserve
--exclude=hiberfil.sys --exclude=pagefile.sys . ; ) " | tar xvp
--atime-preserve
====
Man beachte wiederum das Quoting (also was wo ausgefuehrt wird).
Wobei, AFAIR kann auch tar selber ueber's Netz, aber oben hab ich's
eben per SSH gemacht (auch wenn's nur ueber ein Crossover-Kabel war);
geraten muesste (ohne excludes):
ssh root@xxxxxxxxxxx \
"tar -cp --atime-preserve -f root@xxxxxxxxxxx:- /mnt/hda1"
das Aequivalent sein. Wobei man statt stdout ggfs. auch gleich nen
Dateinamen angeben koennen sollte:
ssh root@xxxxxxxxxxx \
"tar -cp --atime-preserve -f root@xxxxxxxxxxx:./foo.tar /mnt/hda1"
Wie das aber dann mit Zugriffsrechten usw. etc. pp. aussieht weiss ich
nicht, ich habe eben fuer obiges Backup die einfache Variante mittels
stdin/-out genommen, weil ich da nicht viel rumprobieren musste, denn
ich hatte den Laptop mit der IP .2 nur kurz zum reparieren da und
wollte mich nicht gross mit der u.a. ssh(d) Konfiguration hueben und
drueben (ein Knoppix auf dem WinXP Laptop) befassen.
-dnh
--
Bei uns sagt man, je nach dem wo man sich gerade aufhält,
entweder Scheißteil oder Drecksding und manchmal auch
Gehtschonwiedernichtdiescheiße dazu. -- U. Eckhardt ueber Notes
| < Previous | Next > |