similar to: Documentation bug regarding serial console support

It creates the directories as it needs them. If you want to watch it looking through files it doesn't need to copy you can add -ii (see --itemize-changes for what the output means). On 03/20/2018 05:24 PM, Bráulio Bhavamitra wrote: > > > On Tue, Mar 20, 2018 at 5:49 PM Kevin Korb <kmk at sanitarium.net > <mailto:kmk at sanitarium.net>> wrote: > > Nothing

Rsync only cares about the modification time. The ls command usually abbreviates the timestamp so it is better to use the stat command on one of the problem files to see the full thing. On 06/02/2016 06:42 PM, McDowell, Blake wrote: > Cool Thanks! > > Specifically, the timestamps on both <src> and <dest> match for "ls -l" > but do not match for "ls

The man page has a section on what all the itemize-changes flags do. There is a --ignore-times but the result is what you have now, re-copy everything even if the timestamp matches. The best you can really do with storage that can't handle timestamps is to use --update. But if you do that you need to get rid of --partial (part of -P) or else rsync will never complete a file that was

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. On 03/20/2018 02:33 PM, Bráulio Bhavamitra wrote: > > > Em seg, 19 de mar de 2018 11:34, Kevin Korb via rsync > <rsync at lists.samba.org <mailto:rsync at lists.samba.org>> escreveu: > > The performance of rsync with

It is saying the timestamp is wrong and that it is copying the file and changing the timestamp. If it does that every time then either the timestamps are changing on the source or the target isn't storing them. On 06/02/2016 06:13 PM, McDowell, Blake wrote: > Thanks Kevin! I¹m unclear how to read the ‹itemize-changes output. Can you > provide some insight? > > This is a local

Again, --partial only means don't delete the incomplete file if rsync is aborted. Normally rsync will delete the incomplete file so you don't have bogus files laying around. When you rsync to or from a network mount to rsync that is a local copy. To use rsync over the network either your source or your target would be hostname:/path (for rsync over ssh) or hostname::module (for an

I have never seen rsync do that. What exactly are you doing? On 04/07/2017 03:07 PM, McDowell, Blake wrote: > 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

If you are doing a local only copy (rsync isn't networking) then --whole-file is forced. There is no benefit of reading and checksumming files to reduce network transfer when there is no network transfer. You said you were moving data to a remote server so I assume you are using a network mount of some kind to make it a local copy instead of letting rsync do the networking. Anyways, if

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 if you see >f it is doing something to the file. At least a delta-xfer. If it was just a metadata change it would show cf. If you see an >fc without a t then that is an example where rsync found a file that didn't match even though the timestamps did. That isn't supposed to happen very often. On 10/28/2015 01:19 PM, Clint Olsen

Hi Kevin, Just did: same result. -- Best regards / Met vriendelijke groet, Aron Rotteveel 2015-03-27 14:32 GMT+01:00 Kevin Korb <kmk at sanitarium.net>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Try it without any --delete options. > > On 03/27/2015 09:31 AM, Aron Rotteveel wrote: > > I am now running with --delete --numeric-ids --relative but the

Anyone have any other ideas I could try to debug this issue? :) -- Best regards / Met vriendelijke groet, Aron Rotteveel 2015-03-27 16:02 GMT+01:00 Aron Rotteveel <rotteveel.aron at gmail.com>: > Hi Kevin, > > Just did: same result. > > -- > Best regards / Met vriendelijke groet, > > Aron Rotteveel > > 2015-03-27 14:32 GMT+01:00 Kevin Korb <kmk at

The errors column is 0. The drop column is 18. The second bit number is the number of packets which should grow. At least that is how I read it. Column makes it more readable in a terminal but not so much in an email. On 12/21/23 14:18, Alex wrote: > Can someone help me determine if these errors are normal or if this > could somehow be the cause? I've removed the last three

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If it seeing the files as new then I agree that stat won't help. It might have explained some other itemize output. Since it is seeing the files as new then they must not be where it is looking. Meaning that your link-dest parameter must not be appropriate for your target. On 01/10/2015 08:49 PM, Clint Olsen wrote: > On Sat Jan 10 2015 at

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 try: --link-dest=../backup-2016-02-01-0100 On 02/08/2016 04:51 PM, Sam Holton wrote: > 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 >

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

Hi I would like to have changes (chown) in the destination. However, some files did not changed size or rights. All files should have new owner. Thanks, Regards,CJ Em Quinta-feira, 10 de Setembro de 2015 20:26, Kevin Korb <kmk at sanitarium.net> escreveu: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rsync does not change anything on the source.  Only on the target. Only

I am now running with --delete --numeric-ids --relative but the problem still persists. -- Best regards / Met vriendelijke groet, Aron Rotteveel 2015-03-27 14:22 GMT+01:00 Kevin Korb <kmk at sanitarium.net>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Try also removing --delete-excluded. Without those two options there > should be no reason for rsync to require

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --checksum generally takes a lot longer than --size-only. A delta transfer generally goes quicker than a checksum. However, if you want to make a list of what is corrupt a checksumming utility that is less stupid than rsync can be useful. I say that because rsync's - --checksum is entirely unintelligent. It will checksum every single file on

Hi, now it's time to come back to this topic. As supposed, the missing hardlinks where no issue of rsync. I am not sure if pairing aufs (http://aufs.sourceforge.net/) and rsync -RH will catch each and every hardlink compared to a single filesystem, but it seems to work very reliable. I tried mhdfs and aufs. Aufs is faster and very stable (I am on wheezy kernel 3.2). So at last I have my

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remove the -n and look at the results. You would be copying the one dir into the two dir instead of copying the contents of the one dir into the two dir. On 09/30/2015 08:28 PM, Ronald F. Guilmette wrote: > > In message <560C79FF.5010302 at sanitarium.net>, Kevin Korb > <kmk at sanitarium.net> wrote: > >> Because you