similar to: rsync: "-c" option clarification

Before anyone yells at me, yes, you can use rsync's --checksum to detect (and fix) files that are incorrect despite having correct timestamps and sizes. This would mean that a previous rsync had been corrupted not the current one. But it is important to note that this would only be reported to you if you also use --itemize-changes and what to look for (a file with a c but not an s or a t).

Hi This is a very delayed response but thanks very much for your answer, it is appreciated. It seems that if you do an rsync a second / subsequent time with the "-c" (--checksum), say for data that has not changed, it would have to generate checksums from the files on disk at both ends, even if the size and timestamps are the same, is this not the case ? If it is, then it would seem

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

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.

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

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

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]

Hi, I've configured 'backuppc' to transfer files via rsyncd, with enabled checksums. Whith one of the shares I get the error (in syslog): --------------------------------------------------------------------- robbe rsyncd[2183]: ERROR: out of memory in receive_sums [sender] robbe rsyncd[2183]: rsync error: error allocating core memory buffers (code 22) at util2.c(106)

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

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,

Hi, I'm having trouble with --compare-dest, to copy only files that differ in content. Here are the commands used thusfar: rsync -av --checksum --delete --progress --stats --compare-dest=../old new/ new_archive rsync -av --checksum --delete --progress --stats --compare-dest=../new old/ old_archive old/ a.txt new/ a.txt Note: both a.txt are the same (except for a different

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Normally, I would say that --checksum is actually slower than just letting rsync re-copy everything and therefore is almost always the wrong thing to do. However, in this case, you really don't want to overwrite the running OS even with files that are essentially the same. So, if the system is running from that storage then --checksum might

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,

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

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:

> You are missing the point of the checksum. It is a verification that > the file was assembled on the target system correctly. The only > post-transfer checksum that would make any sense locally would be to > make sure that the disk stored the file correctly which would require > a flushing of the cache and a re-reading of the file. Rsync has no > capability to do this

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

Hello. Please see http://unix.stackexchange.com/a/66702. I would like to have confirmation whether or not rsync verifies the transferred files' integrity at the target location by checksumming as advertised in the manpage: """Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is

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