rsync copies files again and again, even if old

Hi,

maybe I've got your answer : consider using the -u option too, which stands for 'update'.

With this option on, rsync won't copy the file if the destination file is 'newer' than the origin (approximately verbatim from the man page).
For what I've tested, if the file has the same modification date & time it is not copied, which seems to be the behaviour you're searching for.

Michel

Hi Xiao Di Di,

> The problem seems to appear when I sync to a volume

which was mounted with "Ignore Ownership"...

That's hardly surprising. I think that checking "Ignore Ownership" hides more than just the file's owner. I believe that it also hides permissions and maybe other stuff. Anyway, when we tested it a while back, the owner showed up in the GUI as the user that was logged into the GUI. However, when a file is copied from such a volume, the owner is empty.

We didn't do a detailed analysis but I feel confident that the file's metadata would appear to rsync to be different from the original and so it makes sense that it would feel the need to update the files no matter what flag you give to rsync. Thus, I don't recommend ever mounting a volume with "Ignore Ownership" checked when it's going to be used as you're using it.
--
Gary
~~~~
"If anything can go wrong, it will."
-- Edsel Murphy

I have submitted the following feedback:

Here are 2 cases where "rsync -E" failed (rsync version 2.6.3 protocol version 28)

1st case: Label

Assuming "test.txt" in folder "test-o" (touch test-o/test.txt) :

rsync -E -av --delete test-o/ test-d

building file list ... done
.DS_Store
. .DSStore

ok, both directory are in sync
Now setting a label to "test-o/test.txt"

rsync -E -av --delete test-o/ test-d

building file list ... done
.DS_Store
. .DSStore
._test.txt

ok, both test.txt file labels are in sync
Now removing the label to "test-o/test.txt"

rsync -E -av --delete test-o/ test-d

building file list ... done
rsync: delete_one: unlink "/Users/xxx/Desktop/test-d/._test.txt" failed: No such file or directory (2)
.DS_Store
. .DSStore

I would expect "test-d/test.txt" label to be removed but is remains, only new label can be synchonized.

2nd case: Ownership & Permission

Same environment, setting "test-o/test.txt" to "Read Only"

rsync -E -av --delete test-o/ test-d

building file list ... done
. .DSStore
._test.txt

Ok, "test-d/test.txt" gets "Read Only", then setting "test-o/test.txt" to "Read & Write"

rsync -E -av --delete test-o/ test-d

building file list ... done
.DS_Store
. .DSStore
._test.txt

I would expect "test-d/test.txt" permission to return to "Read & Write" (ls -l confirms the permission).

One thing to be aware of when using rsync to copy metadata, is that when a files Change time is more recent that it's Modify time on a HFS+ volume it is not possible to tell whether it's extended attributes have been modified since the last rsync run, so rsync must recopy the extended attributes even if they haven't changed. The version of rsync that comes with tiger doesn't even try to determine if the metadata has changed, it just recopies it regardless.

Most of the other issues with rsync that have been mentioned here are actually due to bugs in the way rsync on tiger handles extended attributes (using the -E option).

My solution to these issues was to create a replacement rsync for tiger, which you can download from here if you are interested:

http://www.onthenet.com.au/~q/rsync/

Seeya...Q

Powerbook G4 Mac OS X (10.4.3)