How to exclude directories from getting their metadata updated? (Macintosh HFS+ with rsync 3.0.5)

[Stefan Nowak]

Dear Matt McCutchen!

On Mon, 2009-03-09 at 01:48 +0100 Matt McCutchen wrote:

> On Mon, 2009-03-09 at 01:00 +0100, Stefan Nowak wrote:
>
>> I am doing a recursive sync on a Macintosh, hence HFS+ filesystem,
>> with rsync 3.0.5 installed through MacPorts. I am amazed of rsync's
>> metadata capability! Let me tell you everything works amazingly
>> perfect! When I change i.e. the Finder color labels, and sync that
>> file, rsync successfully only transfers the delta, hence the metadata
>> only! Very effective!
>
> I'm glad to hear it.  That's a result of Mac OS 10.4+ exposing all  
> that
> metadata as POSIX-style xattrs and the improvements made to rsync's
> xattr support to handle such large xattrs efficiently.
>
>> Now, for my particular purpose, I want all this behaviour, except  
>> that
>> directories are not updated with metadata (particularly the date time
>> stamps).
>
> I don't see what's harmful about copying the directory metadata.   
> But if
> you dislike it, you can disable copying of the modification times with
> --omit-dir-times.  That option doesn't currently affect creation  
> times;
> maybe it should.  To disable copying of permissions and user/group
> ownership, you could use the stronger --omit-dir-changes provided by  
> the
> maintained patch omit-dir-changes.diff.

Directory metadata is not harmful, neither copying .DS_Store.

But I intentionally don't want it, because omitting .DS_Store gives me  
the opportunity to have different Finder views/sorting options for the  
same directory(paths) on source and target.


Regarding directory time updating I had some little thinking:

1) rsync only updates directory metadata if source dir is newer than  
target dir. Right? So if I added files to target dir more recently  
than to source dir, rsync would not update the target dir time. I  
consider this as rsync's desirable behavior for me.

2) And if I added files to source more recently than to target, then  
the source dir time would change to when the most recent file was  
added, and rsync would send these time update to target dir, which  
afterwards also will contain those very recent files. As these files  
are new to "my personal realm", when they were first added to  
regardless whatever storage device, I also assume it as desirable that  
if they are synced to somewhere else, that their future parent dir  
keeps this "new to my personal realm" date, rather than the date of  
the sync.

If these my assumptions are true, than I would say that I am not  
anymore opposed to updating target dir time!
Please confirm!

> BTW, --rsync-path serves no purpose on a local copy.

Thanks for this remark. I just put it there to avoid, that the local  
rsync 3.0.5 (in the MacPorts path) accidentially connects to the  
default Leopard rsync 2.6.9 (which has had precedence in my shell  
execution path) as its "remote" engine.
So if you call rsync with a source and target, which are both local,  
rsync is intelligent enough to connect to itself (its very own version  
number)? Really? Please confirm. Or does my additional argument make  
sense to be on the safe side?

Now I changed my .bash_profile to that the MacPort dirs are before the  
system builtin dirs. I googled for "site:lists.macosforge.org path  
precedence" and found my answers.

Thanks! Best regards,

Stefan Nowak

>> I USED THIS CODE
>>
>> /opt/local/bin/rsync \
>> --rsync-path="/opt/local/bin/rsync" \
>> --protect-args \
>> \
>> --archive \
>> --crtimes \
>> --hard-links \
>> --acls \
>> --xattrs \
>> --fileflags \
>> \
>> --exclude=".*" \
>> --exclude="Icon*" \
>> \
>> --verbose --verbose \
>> --itemize-changes \
>> --stats \
>> --progress \
>> \
>> --dry-run \
>> \
>> ~/Movies/VideosPartially/ \
>> /Volumes/VideoAll/