Link-dest breaks on uid/gid mismatches

[Kevin Korb]

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

You might want to look into --fake-super.  It can store metadata
things (like ownership) in the file attributes instead of setting them
on the file.

On 06/11/12 15:25, Chris Davies wrote:
> I want to use rsync to backup a couple of Windows systems to a
> central point. To this end I installed the "DeltaCopy"
> implementation of an rsync server on the Windows boxes. On the
> central server I have rsync 3.0.7 running on a Debian GNU/Linux
> distribution. (I also have a similar configuration but with a QNAP
> - a NAS with bells on - as the central backup point. Since both
> exhibit the same behaviour I'm going to stay with the more common
> scenario.) I also have rsnapshot in the mix but to keep things
> simple I'm going to ignore that for now.
> 
> A cut-down example rsync command could be something like this,
> 
> rsync -avxH --delete --numeric-ids --relative --delete-excluded 
> --modify-window=1 --password-file=/etc/rsnapshot.secret 
> --link-dest=/backup/last/
> rsync://rsync@windows/DocumentsAndSettings /backup/this/
> 
> If this call contacts a Linux based system, the hard links between
> files in /backup/last/... and their unchanged counterparts in
> /backup/this/ are created by the --link-dest option as expected. If
> this contacts a Windows based system running DeltaCopy they are not
> linked. Ever.
> 
> I believe I have narrowed this down to a mismatch between the
> UID/GID values on the Windows side and the Linux side. What appears
> to be happening is that the Windows system is providing UID/GID
> values in a range that cannot be handled by the Linux system, and
> so it is truncating/converting them to 0/0. Then, when the next
> rsync runs, the UID/GID values provided by the Windows system do
> not match 0/0 and so copy is made of the file. (This is fast as
> it's built from the --link-dest item, but nevertheless it's a
> copy.) The resulting copy cannot have its UID/GID values applied
> correctly as they are out of the valid range on the Linux side, and
> so they are again truncated/converted to 0/0. And so on.
> 
> The work-around is to apply --no-owner and --no-group to the rsync 
> command line, at which point the files are owned by the caller of
> the rsync command on the central server and --link-dest can work
> as expected. However, I believe a better solution would, if
> possible, be to force the UID/GID values into a valid range before
> comparing them to an existing file referenced via --link-dest.
> 
> Additional comments - 1. I haven't tried an alternative Windows
> client (e.g. cygwin/rsync) as this is outside the scope of what I
> can change on these systems. Therefore I cannot be sure whether
> this is a client or server issue, i.e. I cannot confirm that this
> fault report belongs to rsync rather than to DeltaCopy 2. I did get
> a UID/GID range error at one point but I can neither reproduce it
> nor remember it sufficiently accurately to want to cite it here
> 
> Any other thoughts, please? Should I report this as a bug?
> 
> Cheers, Chris

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	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.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/WVAQACgkQVKC1jlbQAQek8QCeKMdRjqg1asyH4sw9RUovDW43
s5cAoLK1NOFFDHWRpgfZCq0gZcLmTSX9
=IAs7
-----END PGP SIGNATURE-----