Copied file vanishes when client is OS X

Ed Holden eholden at
Mon Nov 24 21:32:28 GMT 2003


Thanks for responding.  Interestingly enough I noticed a post on one of 
the Samba lists this morning in which someone else recommended 
upgrading to Samba 3 for better OS X compatibility.  So I upgraded.

It works great.  But it didn't solve the problem.  The specific file 
with which I've had the most luck duplicating the problem still 
disappears after the copy from OS X to Samba is complete.  The .DS_Store 
file actually gets written, and after the target file vanishes the 
.DS_Store file remains.

I tried copying the problematic file into another folder on the Samba 
server that is under the same share ... and it worked fine.  Same 
permissions on both folders, by the way.  and I can create a new folder 
with a similar name and the problem occurs there as well.  It's pretty 

another thing I tried was going back to the folder with most problems 
and, on the command line, removing all files, including .DS_Store.  So 
it was a fresh folder, totally empty.  I copied the file ... same 

Any other ideas for troubleshooting?

Thanks again,

On Tue, 25 Nov 2003, Matthew Geier wrote:

> On Tue, 2003-11-25 at 01:59, Ed Holden wrote:
> > The Mac does some unusual things when it tries to write the file, 
> > including creating a .DS_Store file, as well as a temporary version of 
> > the target file beginning with the ._ string.  Still, nothing really 
> > suspicious.  I suspect that this is an issue with Mac OS X dropping the 
> > file prematurely, and a Google search reveals that OS X users have seen 
> > similar problems, but only with Samba shares.  Also, it doesn't happen 
> > to all files.
>  The .DS_Store is the desktop control file, not majorly important, but
> important. The ._{string} file IS important - It's the resource fork
> part of the file and MacOS gets a little upset if they go missing. It is
> not a tempory file.
>  Possibly in your case the resource file is not being written correctly
> for some reason (hide dot files?), OSX is deciding that the resource
> fork part of the file didn't write, aborting the copy and deleting the
> otherwise sucessfully copied data fork as it 'backs out' the copy.
>  OSX would probably be a lot happier with Samba 3 so that it can write
> Unicode filenames....

Any information, including protected health information (PHI), transmitted
in this email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential and or
exempt from disclosure under applicable Federal or State law. Any review,
retransmission, dissemination or other use of or taking of any action in
reliance upon, protected health information (PHI) by persons or entities other
than the intended recipient is prohibited. If you received this email in error,
please contact the sender and delete the material from any computer.

More information about the samba-technical mailing list