osx 10.6 strange rsync errors

[Robert DuToit]

On Apr 6, 2010, at 9:14 AM, Benjamin R. Haskell wrote:

> On Mon, 5 Apr 2010, Robert DuToit wrote:
> 
>> Hi Matt,
>> 
>> I set up a simple test with a nest of directories ( aa > bb > cc > dd 
>> &ee) with 1 file in each.  running rsync from OS 10.6 to another Mac 
>> with OS10.5 there seems to be no problem. When doing the reverse I am 
>> seeing the odd behavior.
>> 
>> Below is the log from running the options
>> 
>> -aHAXN --fileflags --force-change -stats -vvv  
>> 
>> note that the lines 
>> 
>> "rsync: mkstemp "/Volumes/xxx/testaaa/aa/..DS_Store.gnG29l" failed: No 
>> such file or directory (2)" 
>> 
>> are correct in that there are no such files but why does it think 
>> there are?
> 
> Those files are rsync's temporary files, which it transfers first, then 
> atomically moves into place.  Note the many other entries like:

Yes I see now that something in that process of temp files goes awry.

> 
> /path/to/.ORIGINALNAME.XXXXXX
> 
> e.g.: ORIGINALNAME = splittersize.h and XXXXXX = hVRihb in the following:
>> set modtime of aa/bb/cc/dd/.splittersize.h.hVRihb to (1236212797) Wed Mar  4 19:26:37 2009
>> renaming aa/bb/cc/dd/.splittersize.h.hVRihb to aa/bb/cc/dd/splittersize.h
> 
> So, it appears something has changed between 10.5 and 10.6 with how the 
> annoying-to-non-OSX users .DS_Store file is handled.  I just ran into 
> __MACOSX/.DS_Store files in a ZIP file the other day.  Annoying because 
> they force me to have to filter out the garbage files:
> unzip file.zip -x '__MACOSX/*'
> 
> A possibly interesting (probably not) experiment would be to create ZIP 
> files on each machine, then open them on a non-OSX machine to see 
> whether 10.6 creates a file without the .DS_Store files.
> 
> See: http://en.wikipedia.org/wiki/.DS_Store  for the purpose of the 
> files.  (basically, per-folder Finder preferences)
> 
> 
>> They don't exist on source or dest. They do however get created on the 
>> destination. It seems in my test that there is one created for every 
>> directory. However, the original .DS_Store files are not copied over 
>> just the new ones with the odd extra dot prefix and the cryptic 
>> extension on the end. The new odd .DS_Store files take the place of 
>> the normal ones that should be created by the finder.
>> 
>> I don't know if this sheds any light at all on this. Others have 
>> reported that these files get created by the thousands on the 
>> destination. Not only .DS_Store files but other hidden files.
> 
> My guess is that one ..DS_Store.XXXXXX file is created per-directory 
> per-transfer.  Other hidden files are likely created during failed 
> transfers.
> 
> If something changed between 10.5 and 10.6 regarding default permissions 
> on .DS_Store files, that might explain it.  And maybe the files are 
> created automatically at an earlier time (so can't be overwritten by the 
> rename). But I'm not sure what the best solution would be.  The 
> .DS_Store files may or may not be something each user would want to 
> keep.

You can live without the .DS_Store files though they do hold directory info but the many root level hidden files are part of the OS. It seems any hidden files (with a dot prefix) cause this to happen - though I haven't tested yet at root level.

I checked out dtrace (OSX version of strace) but it seems a bit complicated and I don't know how to use it yet. If anyone has maybe they can let me know. 

Thanks, Rob

> 
> -- 
> Best,
> Ben