Hallo, On Sun, 06 Oct 2002, Jan Trippler wrote:
On Son, 06 Okt 2002 at 06:15 (+0200), David Haller wrote:
On Sun, 06 Oct 2002, Jan Trippler wrote:
On Sam, 05 Okt 2002 at 15:36 (+0200), David Haller wrote:
On Sat, 05 Oct 2002, Jan Trippler wrote: [...]
# 1. Schritt: alles was nicht symlink ist kopieren: cd quelle find . -not -type l -print | cpio -pdm ziel
# 2. Schritt: symlinks holen: find . -type l -print | while read i; do q=`readlink $i | sed 's#^quelle#ziel#'` ln -s $q ziel/$i done
Och, das geht auch allgemein ;) Hab jetzt aber keine Lust da jetzt z.B. mit tar zu testen...
So? Zeigen! *fg*
Aber gern! [...] /tmp/test $ cd quelle /tmp/test/quelle $ find . -type f -print0 | tar cp --null -T - \ | tar xp -C /tmp/test/ziel/ [...]
Ah, auf die Idee bin ich nicht gekommen! Aber wenn man es sieht, dann ist es einleuchtend, der Option -T stdin vorzusetzen.
*hehe* Eine Datei ist eine Datei ist eine Datei oder auch ein Verzeichnis oder eine Pipe oder ein FIFO oder ein Socket oder... *g* (ok, tar -T wird die Dateinamen kaum aus nem Verzeichnis lesen, der Rest geht aber ;)
BTW: Den find würde ich aber doch mit -not -type l absetzen, sonst erwischst Du Devices und Named Pipes nicht. Man könnte zwar auch mit find . -type f -o -type c -o -type b ... arbeiten, das wird aber schnell unübersichtlich, vor allem dann, wenn man zusätzliche Optionen hat - -mount z. B. macht sich oft gut, wenn sich andere Dateisysteme innerhalb des zu sichernden Pfades befinden - dann muss man nämlich klammern: find . \( -type f -o -type c -o -type b \) -mount ...
Ack.
Alternativ geht uebrigens auch:
find . -not -type l -print0 | tar cp --null -T - --no-recursion \ | tar xp -C /tmp/test/ziel/
Die Option --no-recursion taucht übrigens nicht im Manual auf.
Nicht? *tstst* Ich hab hier eh nur(!) ein deutsches 'man tar', und das ist (mal wieder) unvollstaendig. Im englischen 'info tar' taucht '--no-recursion' sehr wohl auf. Und authoritativ was vorhandene Optionen angeht ist immer '--help' ;)
Wenn ich es recht verstehe, würden ohne sie Dateien in den Unterverzeichnissen doppelt kopiert werden, da sie einmal durch find gemeldet werden und dann noch durch den (rekursiv arbeitenden) tar archiviert werden, korrekt?
Jup.
Dem kann man durch einen erweiterten find begegnen: find . -not \( -type l -o -type d \) ...
Jup. Oder eben mit dem '--no-recursion', s.o. die 2te Variante von mir.
Und statt -print0 | tar cp --null -T - muesste auch '-print | tar cp -T -' klappen, aber das habe ich jetzt nicht getestet.
IMHO ist doch der Unterschied nur die korrekte Behandlung von Dateinamen mit Zeilenumbruch, oder?
Fast. Das gilt (AFAIK) fuer alle Dateinamen mit Zeichen aus $IFS. Also auch Leerzeichen, Tab oder was auch immer gerade in IFS steht (z.B. ein Doppelpunkt ;) Gerade aber bei Backups denke ich ist es vorteilhaft ASCII NULL als (einziges) Trennzeichen von Dateinamen zu verwenden... Ah, 'info cpio' verraet mir gleich als erste Option: ==== Options ======= `-0, --null' Read a list of filenames terminated by a null character, instead of a newline, so that files whose names contain newlines can be archived. GNU find is one way to produce a list of null-terminated filenames. This option may be used in copy-out and copy-pass modes. ====
Der fundamentale Unterschied zwischen cpio und tar ist: cpio liest die Liste der _Dateinamen_ von stdin, tar höchstens die _Inhalte_ der Dateien. Du kannst ähnliche Sachen wie Schritt 1 natürlich mit tar machen, brauchst dazu aber IMHO mindestens einen zusätzlichen Schritt: Das Erzeugen einer Dateiliste als (temp.) Datei.
Nein. s.o. tar -T liest Dateinamen aus einer Datei. Und diese kann eben auch /dev/stdin sein (was wie bei tar ueblich als '-' angegeben werden kann) -- warum auch nicht! Man lese 'tar --help' *fg*
Ja ja, ich habs ja geschnallt ;-) Aber mal ehrlich: Ist die Zeile mit cpio nicht wesentlich kürzer und übersichtlicher anzuschauen (mal abgesehen davon, dass da nur 1 Pipe und nur 1 Kommando neben dem find nötig ist)? Abgesehen davon ist es beeindruckend zu sehen, wie leistungsfähig GNU tar ist.
Jo. Allerdings geht's z.B. zumindest mir so, dass ich das find meist nicht brauche, und tar einfach auch besser kenne... Siehe z.B. das Thema "Partition kopieren" usw... ;) Tar verwende _ich_ halt fast "instinktiv" und praktisch taeglich, bei cpio muss ich immer alles nachlesen ;) Ja, ich weiss, das liegt v.a. nur an mir, nicht an cpio *g* 'tar' ist aber halt auch ein Standard Archivprogramm, in dem fast jede Software fuer *nix daherkommt ;) Und nein, fuer komprimierte _Backups_ ist tar IMO nicht geeignet, da nur ein gekipptes Bit einen ganzen Kompressions-Block (oder gar das ganze Archiv?) kaputt macht, weswegen ich dafuer auch afio verwende... Andererseits kann eben diese Eigenart auch ein Vorteil sein, z.B. um eine einfache Kontrolle zur Datenintegritaet zu haben oder wenn es _mehrere_ aehnliche Dateien sind: da faellt mir naemlich noch was nettes zu tar ein: ich habe neulich mal Spielstaende via Diskette transferieren wollen... Ich stell's mal nach: $ cd /tmp/test/tar $ ls -l total 10676 -rw-r--r-- 1 dh dh 295823 Aug 15 16:34 save000.mm6 [..] -rw-r--r-- 1 dh dh 296098 Aug 15 16:27 save039.mm6 $ du -hs . 10M . $ bzip2 -9 * $ du -hs . 6.2M . $ bunzip2 * $ tar cIf saves.tar.bz2 * $ du -h saves.tar.bz2 3.1M saves.tar.bz2 Da schlaegt dann die Redundanz zwischen den einzelnen save0* zu, die durch die grossen Bloecke von bz2 beim .tar zum Tragen kommen kann, aber nicht bei den einzelnen Dateien. Im Durchschnitt werden da wohl je 3 Dateien gemeinsam komprimiert und da sie sich nur wenig unterscheiden (Spielstaende teilw. im Minutenabstand), kann bzip2 dann die Bloecke zusammen komprimieren und so entsprechend besser komprimieren... Hm. Man muesste bzip2 mal so aufbohren, dass auch noch groessere Bloecke als 900kb moeglich sind, da koennte obiges Beispiel dann wohl nochmal deutlich kleiner werden ;)) In der Praxis war obiges fuer mich bedeutend, denn mit tar reichten mir: $ echo "scale=2; `du -sk saves.tar.bz2 | cut -d' ' -f1` / 1759" | bc 1.78 mit 1760kb formatierte Disketten (die ich hatte), ohne haette ich $ echo "scale=2; `du -sk . | cut -d' ' -f1` / 1759" | bc 3.63 Disketten gebraucht... (die ich nicht hatte ;) Praktisch habe ich dann aber 2 Archive gemacht (jew. so, dass das tar.bz2 noch auf eine Diskette passte) und nicht split verwendet... Bei der Variante (ein Archiv / Diskette) haben mir mit tar immer noch 2 Disketten gereicht, ohne tar haette ich IIRC 6 Disketten benoetigt... Ohem... Warum erzaehl ich das alles??? Achja, *g*, JEDES der 3 genannten Tools (tar/cpio/afio) hat seine Vor- und seine Nachteile und seine Anwendungsfaelle! "Die Kunst"[tm] ist wohl, das fuer den jeweiligen Anwendungsfall am besten geeignete auszuwaehlen, wobei ich hoffe, dass dieser Thread ein wenig Hilfestellung geben konnte/kann, das jeweils geeignete Programm auszuwaehlen :) -dnh, *gnihihi* good sigmonster, have a cookie! -- There is a green, multi-legged creature crawling on your shoulder.