similar to: rsyncing from a compressed tarball.

Mike, As it stands right now, we use xz for our compression, so if rsync had a similar option for xz that would probably be an improvement. However, I think being able to decompress directly to the remote system would save more; elsewise I don't see how I'm going to be able to avoid untarring and uncompressing the whole xz file on the other end. thanks much, ed On Tue, Dec 6, 2016 at

On Tue, Mar 20, 2018 at 5:49 PM Kevin Korb <kmk at sanitarium.net> wrote: > Nothing there should be preventing incremental indexing. That means it > should start copying as soon as it finds a file that needs to be copied. > Doesn't it tries to create all (empty) directories first? > On 03/20/2018 02:33 PM, Bráulio Bhavamitra wrote: > > > > > > Em seg, 19

OK. Thanks. Where can I find information regarding how to interpret —itemize-changes? The timestamps aren’t changing, so the target must not be storing them, which I have no idea why. The directory I’m writing to is 777. What is the flag to tell rsync to ignore the timestamps? Thanks, Blake On 6/2/16, 6:18 PM, "rsync on behalf of Kevin Korb" <rsync-bounces at lists.samba.org on

Em seg, 19 de mar de 2018 11:34, Kevin Korb via rsync <rsync at lists.samba.org> escreveu: > The performance of rsync with a huge number of files is greatly > determined by every option you are using. So, what is your whole > command line? > rsync -avP /data-old/ /data > > On 03/19/2018 09:05 AM, Bráulio Bhavamitra via rsync wrote: > > Hi all, > > > >

Thanks Kevin! I¹m unclear how to read the ‹itemize-changes output. Can you provide some insight? This is a local transfer from an external drive to an internal drive all attached to one computer. rsync -aPh --itemize-changes -n /Volumes/shuttle_05/2012_79_1_14_1__1199_Workprint /Volumes/3TB_LTO/LT003A/ sending incremental file list >f..t.......

Thank you! I run --times when I use rsync (I actually use the -a flag) but the times do not transfer over and if I run rsync dryrun with -i I can see that it wants to transfer the files because of times. When I run rsync a second time with your suggestion the times do transfer over. I don't know why... B ________________________________________ From: rsync [rsync-bounces at lists.samba.org]

Cool Thanks! Specifically, the timestamps on both <src> and <dest> match for "ls -l" but do not match for "ls -lu" or "ls -lc” The storage is just an regular HDD in a mac pro tower. I can’t imagine why it wouldn’t handle timestamps. Also of note - this problem doesn’t exist for every file, just the vast majority. So, that just makes it more confusing. Yes,

How do I transfer just the modification times with rsync? I now the file content is the same but the modification times are different. Is there a way to do this? Every way that I have tried causes the whole file to transfer as well. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Kevin, I haven't specified --whole-file. After entering an rsync command the terminal always reads "delta-transmission disabled for local transfer or --whole-file" but I assume that is just a standard phrase that always appears. So, if I am running partial (-P) and not using --whole-file or disabling the delta-transmission, why would an incomplete file be deleted and the

On Sat Jan 10 2015 at 5:21:33 AM Kevin Korb <kmk at sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > What does --itemize-changes say about that file? Try using the stat > command on the various copies of it to see what is different about them. > In my original message, I stated I used --itemize-changes, and I reported the following: >

Hi Kevin, Thank you very much. I changed my user in the remote machine (su). Then, by trying again with rsync but with no modification in the source folder, I see that file ownership continues the same. Would be possible for rsync to change the ownership in this case (I am not root) ? Thanks, Regards,CJ Em Quinta-feira, 10 de Setembro de 2015 20:01, Kevin Korb <kmk at

rsync in daemon mode is very powerful, yet it comes with one big disadvantage: data is sent in plain. The workarounds are not really satisfying: - use VPN - one needs to set up an extra service, not always possible - use stunnel - as above - use SSH - is not as powerful as in daemon mode (i.e. read only access, chroot, easy way of adding/modifying users and modules etc.) Why was encrypted

is there a script which analyses rsync output with --itemize-changes ? i.e. i would like to have extended information on number of deleted files, created directories, changed files.... i know rsync 3.1.x is better with this, but it`s still not in centos 5/6/7 and i don`t want to update tons of systems to get extended statistics, so i wonder if anbody did an analyze script to get that information

Thanks for the reply. The link-dest is different. It is Feb 1 while the source is Feb 2. I tried setting path = /media/external/ for the daemon and using rsync -a -v -i --delete --link-dest=backup-2016-02-01-0100 --password-file=/media/external/scripts/offsite_rsync.pass /media/external/backup/backup-2016-02-02-0100 backup at 192.168.2.102: :offsite/backup So all three (link-dest, source,

People, This doesn't seem possible - would it be possible to hack a version of rsync to do it? As an exercise, I want to create a VM image (or at least backup of all the files with rsync) from a SCSI drive in an old Red Hat (NOT Enterprise) v5.2 Linux 486 machine (circa 1999 that does have rsync on it but it has protocol problems talking my server). The 486 has: - an ISA Adaptec 1542

Hi, hardlinking (-H) works perfectly while using a syntax like -avhxSDH <SRC> <DEST> Now I have to mirror multiple SRC directories which contain hardlinks. e. g: src1/a is a hardlink to src2/b -RavhxSDH SRC1 SRC2 DEST does not preserve hardlink a and b in DEST. Is there any chance to do that? Thanks lopiuh -------------- next part -------------- An HTML attachment was scrubbed...

What about -c? It seems I'm getting a lot of spurious file transfer candidates when using: -avvznIi --no-o --no-g --no-p It's showing transfers (receive) for many files I know haven't been tampered with. Thanks, -Clint On Tue, Oct 27, 2015 at 7:53 PM, Kevin Korb <kmk at sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > That is correct.

You could try using an automounter, like autofs, in combination with sshfs. It'll be slower, possibly a lot slower, but it should be more reliable over an unreliable connection. I've been using: remote -fstype=fuse,allow_other,nodev,noatime,reconnect,ServerAliveInterval=15,ServerAliveCountMax=40,uid=0,gid=0,ro,nodev,noatime :sshfs\#root at remote.host.com\:/ BTW, I'm not sure

Ok, thank you for this extra info. I have experienced exactly what you described. The rsync dry run is _still_ running after being started at 1:30am PST :) But it is finding the right files to update. Most of the entries are: >fc........ Which is what I want. So, just because I see: >f at the beginning... That doesn't necessarily mean that the file is going to get updated at the

Hi, I see some warnings like the following. Could anybody explains what they mean? Thanks. 19/31274477.pdf 257,169,119 0% 1.26MB/s 0:03:15 (xfr#121, to-chk=848309/1043298)WARNING: 18/32281577.pdf failed verification -- update retained (will try again). WARNING: 19/28879866.pdf failed verification -- update retained (will try again). -- Regards, Peng