xcopy unter Linux
Chris Seidel
ich suche eine Alternative für xcopy ... ... /s /e /h /v /d /i /k /r /y.
Ich glaube das wäre cp -a, nur fehlt mir das /v, also verify.
Quelle ist Ubuntu mit 8.10 ext3 und Ziel ne USB Platte mit ntfs-5. Soll
auch weiter unter Windows lesbar/schreibbar/löschbar bleiben.
Danke
Hier nochmal das xcopy man:
XCOPY source [destination] [/A | /M] [/D[:date]] [/P] [/S [/E]] [/V] [/W]
[/C] [/I] [/Q] [/F] [/L] [/G] [/H] [/R] [/T]
[/U]
[/K] [/N] [/O] [/X] [/Y] [/-Y] [/Z]
[/EXCLUDE:file1[+file2][+file3]...]
source Specifies the file(s) to copy.
destination Specifies the location and/or name of new files.
/A Copies only files with the archive attribute set,
doesn't change the attribute.
/M Copies only files with the archive attribute set,
turns off the archive attribute.
/D:m-d-y Copies files changed on or after the specified date.
If no date is given, copies only those files whose
source time is newer than the destination time.
/EXCLUDE:file1[+file2][+file3]...
Specifies a list of files containing strings. Each string
should be in a separate line in the files. When any of the
strings match any part of the absolute path of the file to
be
copied, that file will be excluded from being copied. For
example, specifying a string like \obj\ or .obj will exclude
all files underneath the directory obj or all files with the
.obj extension respectively.
/P Prompts you before creating each destination file.
/S Copies directories and subdirectories except empty ones.
/E Copies directories and subdirectories, including empty ones.
Same as /S /E. May be used to modify /T.
/V Verifies each new file.
/W Prompts you to press a key before copying.
/C Continues copying even if errors occur.
/I If destination does not exist and copying more than one
file,
assumes that destination must be a directory.
/Q Does not display file names while copying.
/F Displays full source and destination file names while
copying.
/L Displays files that would be copied.
/G Allows the copying of encrypted files to destination that
does
not support encryption.
/H Copies hidden and system files also.
/R Overwrites read-only files.
/T Creates directory structure, but does not copy files. Does
not
include empty directories or subdirectories. /T /E includes
empty directories and subdirectories.
/U Copies only files that already exist in destination.
/K Copies attributes. Normal Xcopy will reset read-only
attributes.
/N Copies using the generated short names.
/O Copies file ownership and ACL information.
/X Copies file audit settings (implies /O).
/Y Suppresses prompting to confirm you want to overwrite an
existing destination file.
/-Y Causes prompting to confirm you want to overwrite an
existing destination file.
/Z Copies networked files in restartable mode.
The switch /Y may be preset in the COPYCMD environment variable.
This may be overridden with /-Y on the command line.
Andreas Delp
> Hallo,
>
> ich suche eine Alternative für xcopy ... ... /s /e /h /v /d /i /k /r /y.
>
> Ich glaube das wäre cp -a, nur fehlt mir das /v, also verify.
Braucht man das noch? Das Diskettenzeitalter ist eigentlich vorbei.
>
> Quelle ist Ubuntu mit 8.10 ext3 und Ziel ne USB Platte mit ntfs-5. Soll
> auch weiter unter Windows lesbar/schreibbar/löschbar bleiben.
Für Datensicherung aus USB-Platte solltest Du Dir mal rsync anschauen, das
überträgt nur was sich geändert hat->Riesen Zeitersparnis
[cut]
HTH, Andreas
Chris Seidel
<spam...@delp-online.de> wrote:
>> Ich glaube das wäre cp -a, nur fehlt mir das /v, also verify.
> Braucht man das noch? Das Diskettenzeitalter ist eigentlich vorbei.
Das sind für mich lebenswichtige Daten, die würd ich ungern wegen einen
fehlenden Bit verlieren...
HDD-Fehler /Tode hatte ich schon massig (Notebook).
> Für Datensicherung aus USB-Platte solltest Du Dir mal rsync anschauen,
> das
> überträgt nur was sich geändert hat->Riesen Zeitersparnis
Hm, wie sicher ist das denn, wenn da nur die geänderten Blöcke übertragen
werden?
Wie gesagt, kann's mir nicht leisten, dass da was fehlt. Ist ein 30 GB
VMWare Image, wenn da irgendwo was drin zerschossen ist, ist das
möglicherweise ganze Image im Ar***.
Bernd Mayer
>> Braucht man das noch? Das Diskettenzeitalter ist eigentlich vorbei.
>
> fehlenden Bit verlieren...
>
> VMWare Image, wenn da irgendwo was drin zerschossen ist, ist das
Hallo,
man kann ja die md5sum von Original und Kopie erstellen und vergleichen.
http://www.linuxcommand.org/man_pages/md5sum1.html
Bernd Mayer
Martin Winkler
>> Fï¿œr Datensicherung aus USB-Platte solltest Du Dir mal rsync anschauen,
>> das
>> ï¿œbertrï¿œgt nur was sich geï¿œndert hat->Riesen Zeitersparnis
Kann ich nur bestï¿œtigen.
>
> Hm, wie sicher ist das denn, wenn da nur die geï¿œnderten Blï¿œcke ï¿œbertragen
> werden?
Sicher genug.
> Wie gesagt, kann's mir nicht leisten, dass da was fehlt. Ist ein 30 GB
> VMWare Image, wenn da irgendwo was drin zerschossen ist, ist das
> mï¿œglicherweise ganze Image im Ar***.
Weder cp noch rsync haben eine von dir gewï¿œnschte Verify-Option. Daraus
kￜnnte man schluￜfolgern, daￜ die meisten Anwender sowie die Entwickler
jener Programme hierfï¿œr keine Notwendigkeit sehen. Andere Schluï¿œfolgerung
kï¿œnnte sein (die dir vermutlich mehr entgegenkommt): Da es Vergleichstools
bereits gibt, gibt es keine Notwendigkeit, diese Funktionalitï¿œt
nachzuprogrammieren. Verwende einfach diff, das genau dafï¿œr da ist.
Also erst kopieren mit rsync oder meinetwegen auch cp,
dann vergleichen mit diff.
Schￜne Grￜￜe
Martin
Roland Damm
Andreas Delp schrub:
>> Quelle ist Ubuntu mit 8.10 ext3 und Ziel ne USB Platte mit
>> ntfs-5. Soll auch weiter unter Windows
>> lesbar/schreibbar/löschbar bleiben.
> Für Datensicherung aus USB-Platte solltest Du Dir mal rsync
> anschauen, das überträgt nur was sich geändert hat->Riesen
> Zeitersparnis
Inzwischen ist erwähnt, dass es im wesentlichen um _eine_ sehr
große Datei geht. Da spart rsync garnichts. Bei vielen Dateien
kann rsync sparen, weil es nicht veränderte Dateien nicht
speichert. Aber bei Dateien die sich geändert haben, muss Quelle
und Ziel gelesen werden, dann verglichen werden, dann Änderungen
speichern... - glaube nicht, dass man da was spart, wenn Quell-
und Zielfestplatte am selben Rechner hängen.
Sind Quelle und Ziel jedoch über eine Internetverbindung
verbunden, die den Flaschenhals darstellt, ist rsync natürlich
eine super Sache.
CU Rollo
Bernd Hohmann
>> Hm, wie sicher ist das denn, wenn da nur die geänderten Blöcke übertragen
>> werden?
>
> rsync überträgt nicht die geänderten Blöcke sondern die gesamte Datei. Dabei
> wird eine Prüfsumme berechnet und mit dem Ergebnis verglichen.
Nein.
rsync bildet blockweise Prüfsummen sowie eine Anweisung, wie eine
vorhandene Datei mit den übertragenen Teilblöcken zu aktualisieren ist.
Dabei findet eine Optimierung dergestalt statt dass der Aufwand einer
Teilübertragung dem Aufwand einer Komplettübertragung in Bezug auf die
Übertragungsgeschwindigkeit gegenübergestellt wird.
Darum wirst Du im LAN nur bei grossen Dateien (sagen wir mal ständig
erweiterte Logfiles ab 50MB) irgendeine Optimierung feststellen.
Bernd
--
Visit http://www.nixwill.de and http://www.spammichvoll.de
jean....@nixwill.de & bernado....@spammichvoll.de
Norbert Hahn
>Hallo,
>
>ich suche eine Alternative f�r xcopy ... ... /s /e /h /v /d /i /k /r /y.
>
>Ich glaube das w�re cp -a, nur fehlt mir das /v, also verify.
Das ist unter modernen Betriebssystemen ziemlich sinnfrei, weil die
kopierten Daten im Cache, also im RAM des Rechners gehalten und dort
mit dem Original verglichen werden, was sich auch noch (teilweise)
im RAM befindet.
Ein sinnvoller Vergleich ist erst m�glich, wenn die Daten mit
Sicherheit auf der Zielplatte auch geschrieben wurden, denn sonst
bekommt man Fehler im Platten-Controller und im Kabel nicht mit.
Das schon erw�hnte diff bzw. md5sum oder �hnliche Programme kann
man zum Vergleich verwenden, aber ich w�rde das erst einige Zeit
nach dem Kopieren tun, evtl. sogar erst nach einem Boot.
Norbert
Bernd Hohmann
>>Ich glaube das wäre cp -a, nur fehlt mir das /v, also verify.
>
> Das ist unter modernen Betriebssystemen ziemlich sinnfrei, weil die
> kopierten Daten im Cache, also im RAM des Rechners gehalten und dort
> mit dem Original verglichen werden, was sich auch noch (teilweise)
> im RAM befindet.
/v löste unter DOS einen Sync aus.
Christian Garbs
Martin Winkler <martin_...@gmx.de> wrote:
> Also erst kopieren mit rsync oder meinetwegen auch cp,
> dann vergleichen mit diff.
Wenn Du mit rsync kopiert hast, brauchst du per Definition kein diff
mehr. Es sei denn, es geht dir um das sicherstellen, dass auf deine
Festplatte auch das geschrieben wurde, was du wolltest. Dann musst du
aber warten bis alle Caches leer sind - und danach kannst du einfach
einen zweiten rsync-Lauf anstoßen :-)
Gruß
Christian
--
....Christian.Garbs.....................................http://www.cgarbs.de
"If it wasn't for bad luck, I wouldn't have luck at all."
(Homer Simpson, Born under a bad sign)
Thomas Orgelmacher
> Also erst kopieren mit rsync oder meinetwegen auch cp,
> dann vergleichen mit diff.
diff mit sehr groï¿œen Dateien geht ziemlich sicher in die Hose
(ok, abhï¿œngig vom Hauptspeicher). Von binï¿œren Daten 'mal ganz
zu schweigen. Dann schon eher cmp oder md5sum...
Gruￜ, Thomas
--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.
Sven Hartge
> Weder cp noch rsync haben eine von dir gewï¿œnschte Verify-Option.
Nicht ganz korrekt im Bezug auf rsync.
Ich habe eine Zeitlang Dateien ï¿œber einen Ethernet-Link rsyncen mï¿œssen,
auf dem durch ein Treiber-Problem (at1le) ab und zu Blï¿œcke von Nullen in
den Strom eingefï¿œgt wurden.
rsync hat dies ohne Probleme erkannt und die relevanten Teile der Datei
neu ï¿œbertragen. Solange, bis die Datei dann korrekt und fehlerfrei
angekommen war.
Sￜ
--
Sig lost. Core dumped.
Michael Baeuerle
> Martin Winkler wrote:
> >
> > Also erst kopieren mit rsync oder meinetwegen auch cp,
> > dann vergleichen mit diff.
>
> Wenn Du mit rsync kopiert hast, brauchst du per Definition kein diff
> mehr. Es sei denn, es geht dir um das sicherstellen, dass auf deine
> Festplatte auch das geschrieben wurde, was du wolltest. Dann musst du
> aber warten bis alle Caches leer sind - und danach kannst du einfach
Nur warten reicht ggf. nicht. Auch nachdem die Platte die Daten
geschrieben hat koennen sie auf unbestimmte Zeit im Cache (der Platte)
verbleiben und werden beim erneuten Lesen dann direkt von dort
geliefert. Das ist bei der Write-back und der Write-through
Cache-Strategie der Fall. So kann man also nicht sicher pruefen ob die
Daten auf dem Medium korrekt geschrieben wurden und lesbar sind.
Ohne genaue Kenntnis der technischen Details von Platte und OS muss man
die Zielplatte IMHO nach dem Kopieren resetten/ausschalten. Nur dann ist
garantiert, dass der folgende Test wirklich mit den Daten auf dem Medium
arbeitet und damit aussagekraeftig ist.
Micha
Thomas Rachel
> /v löste unter DOS einen Sync aus.
Unter Linux tut das sync(1) - nur bringt es hier nix: es stellt zwar
sicher, daß alles aus dem Schreibcache auf der Platte landet, aber ein
darauffolgendes Read liest dennoch aus dem Cache.
Thomas
Thomas Rachel
> * Roland Damm <rolan...@arcor.de> schrieb:
>
>> Inzwischen ist erwähnt, dass es im wesentlichen um _eine_ sehr
>> große Datei geht. Da spart rsync garnichts.
>
> | Bei der Datenübertragung werden Teile einer Quelldatei (die zu
> | übertragende Datei), welche sich bereits in der Zieldatei befinden,
> | nicht übertragen, wodurch viel Transfervolumen gespart werden kann.
Transfervolumen, ja. Aber wenn ich (lokal!) erstmal nachschauen muß, wie
die Zieldatei aussieht, und diese einlesen muß, um aus ihr und der
Quelle die neue zusammenzubauen, kann ich auch gleich kopieren.
AFAIK verhält sich rsync auch genauso, nämlich nur übers Netz sparsam
(wie beschrieben), lokal per Default "einfach".
Thomas
Roland Damm
Bernd Hohmann schrub:
> /v löste unter DOS einen Sync aus.
DOS kannte IMO keinen Plattencache, außer eventuell wenn die
Platte selbst einen hatte.
So oder so muss so eine verify-Option ziemlich tief in dem System
verankert sein. Bis hinab zum Treiber für die Platte müssen alle
Subsysteme damit umgehen können und passend reagieren. An
sonsten bliebt doch nur wieder irgendwo was in irgendeinem Cache
hängen:-)
CU Rollo
Roland Damm
Bernd Hohmann schrub:
>> rsync überträgt nicht die geänderten Blöcke sondern die
>> gesamte Datei. Dabei wird eine Prüfsumme berechnet und mit dem
>> Ergebnis verglichen.
>
> Nein.
>
> rsync bildet blockweise Prüfsummen sowie eine Anweisung, wie
> eine vorhandene Datei mit den übertragenen Teilblöcken zu
> aktualisieren ist.
Ist das alles? Würde man an eine Datei vorne ein Byte anhängen,
dann würden ja alle Blöcke ihren Inhalt ändern (weil sich der
ganze Inhalt um 1 Byte verschiebt) und alles müsste übertragen
werden. Ich hatte mal den Eindruck, das dem nicht so ist: IMO
hatte ich da eine pdf-Datei die ich Stück für Stück änderte,
jeweils änderte sich das Inhaltsverzeichnis am Anfang der Datei,
und dennoch übertrug rsync nicht viel mehr als nur das, was sich
wirklich geändert hatte, also jeweils vielleicht nur 10% der
Datei. Kam mir auch komisch vor, dass das so effektiv läuft.
CU Rollo
Bernd Hohmann
>> /v löste unter DOS einen Sync aus.
>
> DOS kannte IMO keinen Plattencache, außer eventuell wenn die
> Platte selbst einen hatte.
config.sys -> BUFFERS, später dannn SMARTDrive
Beide konnnten über int 21h, 68h (oder so ähnlich) geflushed werden.
> So oder so muss so eine verify-Option ziemlich tief in dem System
> verankert sein. Bis hinab zum Treiber für die Platte müssen alle
> Subsysteme damit umgehen können und passend reagieren.
Das ist kein Problem, jede File-IO Schnittstelle (das geht runter bis
aufs SCSI/ATA-Protokoll) hat ein "flush" Kommando, oft gibts dann auch
ein "invalidate cache" als Sonderoption.
Thomas Bliesener
> Das sind f�r mich lebenswichtige Daten, die w�rd ich ungern wegen einen
> fehlenden Bit verlieren...
Bits gehen �u�erst selten verloren, gelegentlich kann aber mal eines
kippen ... ;-)
>> F�r Datensicherung aus USB-Platte solltest Du Dir mal rsync anschauen,
>> das
>> �bertr�gt nur was sich ge�ndert hat->Riesen Zeitersparnis
>
> Hm, wie sicher ist das denn, wenn da nur die ge�nderten Bl�cke �bertragen
> werden?
WIMRE gibt es laut Autor alle 2^128 Bits einen Fehler.
--
bli
count zero
> Hallo,
>
> ich suche eine Alternative für xcopy ... ... /s /e /h /v /d /i /k /r /y.
>
> Ich glaube das wäre cp -a, nur fehlt mir das /v, also verify.
>
> Quelle ist Ubuntu mit 8.10 ext3 und Ziel ne USB Platte mit ntfs-5. Soll
> auch weiter unter Windows lesbar/schreibbar/löschbar bleiben.
http://www.cis.upenn.edu/~bcpierce/unison/
Für hartneckige Fälle
ddrescue -d -D Quelle Ziel Transfer.log
#v+
[count.zero@Rechner]$ ddrescue --help
GNU ddrescue - Data recovery tool.
Copies data from one file or block device to another,
trying hard to rescue data in case of read errors.
Usage: ddrescue [options] infile outfile [logfile]
Options:
-h, --help display this help and exit
-V, --version output version information and exit
-b, --block-size=<bytes> hardware block size of input device [512]
-B, --binary-prefixes show binary multipliers in numbers
[default SI]
-c, --cluster-size=<blocks> hardware blocks to copy at a time [128]
-C, --complete-only do not read new data beyond logfile
limits
-d, --direct use direct disc access for input file
-D, --synchronous use synchronous writes for output file
-e, --max-errors=<n> maximum number of error areas allowed
-F, --fill=<types> fill given type areas with infile data
(?*/-+)
-g, --generate-logfile generate approximate logfile from partial
copy
-i, --input-position=<pos> starting position in input file [0]
-n, --no-split do not try to split or retry error areas
-o, --output-position=<pos> starting position in output file [ipos]
-q, --quiet quiet operation
-r, --max-retries=<n> exit after given retries (-1=infinity)
[0]
-R, --retrim mark all error areas as non-trimmed
-s, --max-size=<bytes> maximum size of data to be copied
-S, --sparse use sparse writes for output file
-t, --truncate truncate output file
-v, --verbose verbose operation
Numbers may be followed by a multiplier: b = blocks, k = kB = 10^3 =
1000,
Ki = KiB = 2^10 = 1024, M = 10^6, Mi = 2^20, G = 10^9, Gi = 2^30, etc...
Report bugs to bug-dd...@gnu.org
[count.zero@Rechner]$
#v-
--
ln -s /dev/cerebro /dev/null is full
Was ich denke ist leer und es quillt über.
Pseudonym...count.zero@interrupt; verarbeiten, lernen endet bei Null.
Michael Baeuerle
> Roland Damm schrieb:
> >
> > So oder so muss so eine verify-Option ziemlich tief in dem System
> > Subsysteme damit umgehen k�nnen und passend reagieren.
>
> Das ist kein Problem, jede File-IO Schnittstelle (das geht runter bis
> aufs SCSI/ATA-Protokoll) hat ein "flush" Kommando, oft gibts dann auch
> ein "invalidate cache" als Sonderoption.
Mal abgesehen davon, dass das gar nicht unbedingt jede Platte
unterstuetzt: SCSI FUA wird bei Linux z.B. fuer write barriers verwendet
um den Mediumzugriff zu erzwingen obwohl der Write-Cache an ist. Aber wo
ist da ein API (fuer den Userspace ohne root-Rechte) mit dem ein
Programm sagen koennte "lies mal bitte am Read-Cache vorbei vom Medium"
weil es verify machen moechte?
Micha
Thomas Rachel
>> rsync bildet blockweise Prüfsummen sowie eine Anweisung, wie
>> eine vorhandene Datei mit den übertragenen Teilblöcken zu
>> aktualisieren ist.
>
> Ist das alles? Würde man an eine Datei vorne ein Byte anhängen,
> dann würden ja alle Blöcke ihren Inhalt ändern (weil sich der
> ganze Inhalt um 1 Byte verschiebt) und alles müsste übertragen
> werden.
Es handelt sich um rollende Summen, mit denen recht effizient
Datenblöcke wiederfinden lassen.
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2007/08/Recycling-Meister
http://samba.org/rsync/tech_report/
http://samba.org/rsync/how-rsync-works.html
http://samba.org/~tridge/phd_thesis.pdf
Thomas
Roland Damm
Thomas Rachel schrub:
>> Ist das alles? Würde man an eine Datei vorne ein Byte
>> anhängen, dann würden ja alle Blöcke ihren Inhalt ändern (weil
>> sich der ganze Inhalt um 1 Byte verschiebt) und alles müsste
>> übertragen werden.
>
> Es handelt sich um rollende Summen, mit denen recht effizient
> Datenblöcke wiederfinden lassen.
>
>
http://www.linux-magazin.de/Heft-Abo/Ausgaben/2007/08/Recycling-Meister
....
Ach, interessant, so 'einfach' geht das also.
CU Rollo