Problem with rsync'ing a shared filesystem on MacOS

[fillg1]

Hi folks
My MP3 files and the iTunes Library is located on a FreeNAS 11 share. This share is mounted on my MacBook on /Volumes/iTunes. For backup purposes and when I'm on vacation, the directory is rsync'ed to a mobile USB disk, the external disk is mounted on /Volumes/Data

Code:

rsync -atuv --delete /Volumes/iTunes/Library/ /Volumes/Data/iTunes/Library

This works fine. But when I try to rsync the disk 'back', all files on the disk are copied back to the share, regardless if the files are modified or not.

Code:

rsync -natuv --delete /Volumes/Data/iTunes/Library/ /Volumes/iTunes/Library

which is of course not the desired behaviour. This happens with both AFP and SMB shares and it used to work with FreeNAS 9.10.

Any idea what is going on here?

 

[fracai]

It's probably that the file timestamps or permissions have changed and rsync thinks they need to be updated (even permissions can't be updated without transferring ). In fact, I notice that you '-t' to preserve modification times. It's likely that there is a mismatch between those. You can disable timestamp checking with '--ignore-times'. But then rsync will checksum every file, wasting time. Instead, you could use '--size-only', which will use only the file size to determine what needs to be transferred. If you aren't modifying metadata, this shouldn't be an issue. If you are making changes that would update the modification time, but wouldn't change the file size (music metadata is a good candidate) this would skip copying some files that should be transferred.

I think you need to pick a small set of files (an artist where you only have a few tracks?) and run the transfer a few times with verbose logging cranked up. That should be illuminating as to what changes are flagging a file as needing to be sent and how you can skip data that hasn't changed.