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