On Mon, Jul 10, 2006 at 01:16:38PM -0700, Bill Studenmund wrote:
> On Sun, Jul 09, 2006 at 11:58:33AM +0200, Pawel Jakub Dawidek wrote:
> > Maybe you guys will find my experience helpful. I'm working on gjournal
> > (a block level journaling) for FreeBSD and I needed to solve this
> > problem as well.
> > 
> > My first solution to the problem was a magic .deleted/ directory, which
> > was created on mount time. Now, when an object (file or directory) was
> > removed, but still open, it wasn't really removed, but moved to
> > .deleted/ directory. On close the object is removed from this directory.
> > You need to ensure that such file/directory cannot be moved back to the
> > file system. On system crash or a power failure all you need to do is to
> > 'rm -rf .deleted' directory.
> > It worked without problems, but it wasn't really nice, so I implemented
> > another thing...
> 
> I actually think it's a good way to go. Let's all agree on how to find 
> this directory and just use it.

It looks ugly. Maybe the directory could be some special inode, invisible
in the filesystem namespace? (IIRC LFS does this for its Ifile.)

Also, if you unlink all names of an open file, shouldn't fstat(2) on its
descriptor show nlinks == 0?

> The concern I have with something like this is that you're adding new cg 
> and fs_ values. The problem I see with this is that AFAICT ffs doesn't 
> handle versioning very well. I'd rather we not add new fields if we can't 
> tell what fields are in use. :-|

Could this be changed? Ext2fs has an interesting compatibility mechanism,
see http://lxr.linux.no/source/Documentation/filesystems/ext2.txt#L224

Maybe some space could be allocated in superblock for such three bit
fields, and a flag in fs_flags would indicate that they are present?

Pavel