Disabling "quick check"
clint.olsen at gmail.com
Sat Oct 31 21:28:36 UTC 2015
I just wanted to thank you for your help. I was able to get a comprehensive
list using the checksum switch. To summarize I recovered my data with:
-acvzIi --no-o --no-g --no-p
On Wed, Oct 28, 2015 at 10:22 AM, Kevin Korb <kmk at sanitarium.net> wrote:
> -----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 <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.
> >> Thanks,
> >> -Clint
> >> 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:
> >>> 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. 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-----
> Please use reply-all for most replies to avoid omitting the mailing list.
> To unsubscribe or change options:
> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rsync