Changing only file permissions

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No, even if bandwidth is your concern I would say that --checksum is
wrong.  Maybe if bandwidth is so scarse that a few KB vs a few MB
equates to dollars then sure, use --checksum.  Otherwise, letting
rsync re-delta-xfer everything is certainly faster and not much more
bandwidth intensive than --checksum.  Plus that is only if you screwed
up and ran rsync wrongly in the past.  This question shouldn't matter
as you should have synchronized mtime stamps so that rsync knows what
is going on.

In my experience, --checksum is really only useful with
- --only-write-batch, or with --link-dest and known corruption, or with
- --itemize-changes and a watch for hardware induced corruption.

If --checksum didn't checksum absolutely everything on both ends it
might be more useful.  But apparently the use cases for --checksum are
so rare that nobody seems to care that --checksum is so stupid that it
checksums files that have different file sizes (and therefore could
only have a matching checksum if one file is a carefully crafted hash
collision) and it even checksums file that only exist on one (or the
other) end of the connection even though there is no file on the other
end to compare the checksum to.  What a waste of time.

On 04/22/2015 03:57 AM, Hendrik Visage wrote:
> On Wed, Apr 22, 2015 at 9:15 AM, Kevin Korb <kmk at sanitarium.net>
> wrote: Normally, I would say that --checksum is actually slower
> than just letting rsync re-copy everything
> 
>> Depends on the network capacity and costs associated with that
>> bandwidth :(
> 
> and therefore is almost always the wrong thing to do.
> 
>> Nope, not when you are bandwidth and budget constraint ;)
> 
> 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
> actually be useful.
> 
> On 04/22/2015 01:59 AM, Hendrik Visage wrote:
>>>> On Wed, Apr 22, 2015 at 1:03 AM, James Moe
>>>> <jimoe at sohnen-moe.com> wrote: Hello, opensuse 13.2 linux
>>>> v3.16.7-7-desktop x86_64 rsync v3.1.1
>>>> 
>>>> I used rsync to copy /usr/ to another volume with these
>>>> options: --recursive --one-file-system --links --stats
>>>> --itemize-changes --quiet --delete --times After I had
>>>> modified the system to use the new /usr volume, I realized I
>>>> should have added: --perms --owner --group --executability
>>>> 
>>>> So the target volume has everything set as "root root", and
>>>> useful bits like the SetUID mode are missing.
>>>> 
>>>> Is there a way to use rsync to restore only the 
>>>> permissions/owner/user and mode flags on the target volume
>>>> from the source volume?
>>>> 
>>>>> *If* their sizes and times match, then I believe rsync does
>>>>> only the permissions/etc. changes with the -a option.
>>>>> However, I got into the tendency when doing these type of
>>>>> things, to use the -c/--checksum option, that way rsync
>>>>> makes sure the files haven't changed and will
>>>>> copy/update/etc.
>>>> 
>>>> 
>>>>> -- 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

iEYEARECAAYFAlU3WSYACgkQVKC1jlbQAQfSxACg2q8IDYclf6XSKSX3VQF8s7LK
7dgAn3Np86Q1vg+Q88oIY+ua/wEhHcXi
=wncA
-----END PGP SIGNATURE-----