-----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 wrote: > 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 destination? In other words, you're saying that just doing > the delta transfer is more time efficient and rsync won't touch the > file unless _some_ relevant change is observed? It just concerned > me because the file list was extensive, and I definitely don't want > anything copied unless for example the checksums don't match. > > Thanks, > > -Clint > > > On Wed, Oct 28, 2015 at 5:41 AM, Kevin Korb <k...@sanitarium.net > <mailto:k...@sanitarium.net>> wrote: > > --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 both ends including files that only exist on > one end and files that shouldn't match (the size is wrong). At the > end of --checksum you will still have to do the delta xfers that > you would do without it. > > OTOH, you are using --dry-run. If you are trying to generate a > report about what files are corrupted then only --checksum an do > that. It will just do it in the dumbest/slowest way possible. > > On 10/28/2015 02:08 AM, Clint Olsen wrote: >> 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 <k...@sanitarium.net >> <mailto:k...@sanitarium.net> <mailto:k...@sanitarium.net >> <mailto:k...@sanitarium.net>>> wrote: > >> That is correct. Rsync will re-copy (delta xfer unless >> --wholefile) all the files. You can always --dry-run if you >> aren't sure. > >> On 10/27/2015 10:07 PM, Clint Olsen wrote: >>> Hi: > >>> I've been using rsync to create backups for a few years. A few >>> months ago I started experiencing sector errors. I ended up >>> replacing the drive and copying the drive data. It turns out >>> that due to the default behavior of rsync "quick check", some >>> of the files were modified without altering the modification >>> time or size, so these files are still clean in the backup. I >>> would like to recover these files, but I need to defeat the >>> quick check in order to do this. It looks like using: > >>> -I, --ignore-times don't skip files that match size >>> and time > >>> will work. I just want to confirm that this covers it. The >>> long-form of the switch doesn't mention size, so I was >>> concerned this was the right way to accomplish this. If there >>> are any other switches that would be useful in the context of >>> potentially corrupt files, please feel free to chime in... > >>> Thanks, > >>> -Clint > > > > > >> -- Please use reply-all for most replies to avoid omitting the >> mailing list. To unsubscribe or change options: >> https://lists.samba.org/mailman/listinfo/rsync Before posting, >> read: http://www.catb.org/~esr/faqs/smart-questions.html > > > > > > > -- Please use reply-all for most replies to avoid omitting the > mailing list. To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/rsync Before posting, > read: http://www.catb.org/~esr/faqs/smart-questions.html > > > > - -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., - -*~ Kevin Korb Phone: (407) 252-6853 Systems Administrator Internet: FutureQuest, Inc. ke...@futurequest.net (work) Orlando, Florida k...@sanitarium.net (personal) Web page: http://www.sanitarium.net/ PGP public key available on web site. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., - -*~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlYxBG0ACgkQVKC1jlbQAQeUuwCeLWbozz3DbuAXn94/ZnBQaiW5 l94AoNkjkk6QK4Pfjf6qHtOd1ml4xxi8 =lIwU -----END PGP SIGNATURE----- -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
