similar to: [Bug 11422] New: Feature request: add support for Linux libcap[-ng]

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

Thank you. This helps get me closer. One machine shows rsync 3.0.9 and the other shows rsync 3.1.0. Running "rsync --version" both show "ACL, xattr" are supported. Two questions, would the two different version cause it to fail? Second, does the order rsync "receives" the switches matter. Does "-A" and "-X" need to be near the beginning of

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,

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.......

-----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 > problem still persists. > > -- Best regards / Met vriendelijke groet, > > Aron Rotteveel > > 2015-03-27 14:22 GMT+01:00 Kevin Korb <kmk at sanitarium.net >

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

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, > > > >

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]

In message <560C79FF.5010302 at sanitarium.net>, Kevin Korb <kmk at sanitarium.net> wrote: >Because you are making two/one. Change to: >rsync -n -v --itemize-changes -checksum -a one/ two/ OK, I tried it with your suggested command line, and yes, that produces rather more substantially useful results. However... Perhaps I am just a bit thick, but I really don't have any

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

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,

Hi Kevin, I'm not a systems manager so my apologies if I'm a little lost here. I'm an audiovisual conservator/archivist and I use rsync for transferring files, a lot. Yes, I connect to the server and then it shows up as a disk on my desktop and I run rsync between the external drive mounted on my computer and the now mounted server. So, this would be a local copy? And, therefore,

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.

I create a new thread, because the issue is not really the same, but i copy here the thread that made me jump into the list. My issue is not really that it waits before starting copying, but a general performance issue, specially when there are multiple rsync running at the same time. Here is my situation : I have multiple clients (around 20) with users and i want to rsync their home dirs with

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Try also removing --delete-excluded. Without those two options there should be no reason for rsync to require gigs of RAM. Well, unless the other system has rsync 2.x. On 03/27/2015 07:29 AM, Aron Rotteveel wrote: > Yes, I removed "--no-inc-recursive", without success. > > -- Best regards / Met vriendelijke groet, > >

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

With the following server config: log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock [offsite] path = /media/external/ comment = Offsite backup read only = no hosts allow = 192.168.2.0/24 auth users = backup secrets file = /etc/rsyncd.scrt uid = 0 gid = 0 I tried the following for --link-dest and they all tried to transfer all

for pre 3.0.9 which is still standard in centos7 with recent updates, --stats does neither show number of deleted, nor added files Am 17. Dezember 2016 18:06:56 MEZ, schrieb Kevin Korb <kmk at sanitarium.net>: >--stats has most of that information in it. > >On 12/17/2016 08:01 AM, devzero at web.de wrote: >> is there a script which analyses rsync output with --itemize-changes

In message <560C660F.5000202 at sanitarium.net>, Kevin Korb <kmk at sanitarium.net> wrote: >Just add --itemize-changes and --checksum to what you were doing >before and know that it will take a long time. I'm still not getting to where I need to be. Maybe you can explain what has gone wrong in this very simple example: % mkdir one two % echo hello > one/hello % ln