Copied file vanishes when client is OS X

[Benjamin Riefenstahl]

Hi Ed,


Ed Holden <eholden at mclean.harvard.edu> writes:
> I'm eager to see what Apple has to say about it.

Yes, I curious, too. 

> The FAT issue is baffling.  I'm using ext3 on my target partition,
> and the differences between it and FAT should be transparent from
> the client side.

No, I meant a FAT image on the local Mac, not over Samba.  I was
trying to find out if the type of representation of the Mac OS
metadata (of which there are several in Mac OS X) had an influence.

I currently believe that it's a concurrency issue.  Samba (and/or the
smbfs implementation in Mac OS X) does that Windows style automatic
locking, and it looks like the finder uses threads to copy the file
and keep the UI up-to-date at the same time.  For small files the copy
is over before the UI needs to refresh its view.  But for files of a
certain size, the UI updates and the cleanup after the actual copy may
run into locking issues.

The copy thread wants to delete the Mac OS metadata file (which only
contains defaults at this time, so it's redundant), finds that it is
locked by the UI thread and runs its error handler, doing a complete
rollback.  This fits with the logs and with my observation that it
doesn't happen if there are other files with metadata, which would
change the timing.


benny