2.2.5pre1: unlink design flaw

Cole, Timothy D. timothy_d_cole at md.northgrum.com
Thu Jun 13 11:29:49 GMT 2002

> -----Original Message-----
> From: Mike Gerdts [mailto:Michael.Gerdts at alcatel.com]
> Sent: Thursday, June 13, 2002 9:03
> To: Simo Sorce
> Cc: jd at epcnet.de; Samba Technical Mailing List
> Subject: Re: 2.2.5pre1: unlink design flaw
> Under HP-UX 10.20 I ran into issues with automated software 
> updates (via
> package from AFS or rsync, I forget) in that files (executables) that
> were in use could not be unlinked.  As a result the software would
> rename the file with a .OLD extension.  I then would periodically do a
> find through the file system to get rid of all .OLD filess.  What a
> waste of I/O bandwidth.
> The solution that I did not find the time to implement was to create a
> .OLD directory on each mounted file system.  All .OLD files could then
> be moved by the update tool into <mntpt>/.OLD.  Then the 
> cleanup process
> would only have one directory per file system to look at.
> A similar solution could be used here.  The equivalent of the .OLD
> directory could be something that is not exported by samba.  If an
> unlink() fails because of ETXTBUSY, rename() could be used to move it
> out of the shared directory to a directory that is monitored by a
> "deleted file reaper".

The way NFS deals with this is typically for the server to rename unlinked
but open files to .nfs.somethingorother.

More information about the samba-technical mailing list