Disabling "quick check"
kmk at sanitarium.net
Wed Oct 28 17:22:53 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
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
> Which is what I want.
> So, just because I see:
> 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.
> On Wed, Oct 28, 2015 at 5:41 AM, Kevin Korb <kmk at sanitarium.net
> <mailto:kmk at 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.
>> On Tue, Oct 27, 2015 at 7:53 PM, Kevin Korb <kmk at sanitarium.net
>> <mailto:kmk at sanitarium.net> <mailto:kmk at sanitarium.net
>> <mailto:kmk at 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:
>>> 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...
>> -- 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. Kevin at FutureQuest.net (work)
Orlando, Florida kmk at sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the rsync