In  <199612302201.QAA15288@lotharon.endicor.com> , you wrote:

> Followups to tech-kern, where this is more appropriate (ment to do that
> the first time, sorry).
> 
> der Mouse wrote:
> > 
> > This sounds as though it would require a great redesign of the
> > filesystem semantics.
> 
> Well, that was the point :-)
> 
> > Consider unlink().  This is not an operation on a file; it is an
> > operation on file _names_.  unlink() removes a directory entry.  The
> 
> So the handle either needs to be on the directory entry, or neds to have
> memory of how it was found. The sematics are a bit tough with FFS.
> They're a little easier with something like the Amiga FS, where hard
> links are distinguishable from the "true file", or with something like
> the Be FS, where the filesystem has a database table style
> representation and the handle can basically be a row pointer.

[snip]

Acutally, a 

int unlink2(const char *name, const struct stat *statbuf);

would solve the problem.  In essence, you stat/fstat the file first (which
you are going to do anyway (to make sure it's on the device, old enough,
etc.)) and then you pass that stat buf to unlink2.  The kernel can then
verify that <name> is the same object as represented by the information
in *<statbuf> and then proceed with the deletion.  If the information
(dev,inode,generation) doesn't match, unlink2 fails.  The kernel can easily
make this an atomic operation.

You can do the same for rename by two stat buffers (one for the file to
be renamed and one for the directory into which it will be moved).

This isn't the cleanest method but it should be fairly easy to implement.

-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt.html
Westford, MA              Disclaimer: I disavow all knowledge of this message