Re: closefd: closes a file of any process

[Tigran Aivazian]

Hi Werner,

On Wed, 28 Jun 2000 [e-mail] wrote:

> Tigran Aivazian wrote:
> > to a different inode. The real inode is released. Do you think this is the
> > wrong direction too?
> 
> What I don't quite understand about your close mechanism is for what type
> of situation it is intended. It seems to me that only very few programs
> can be expected to continue correct operation if you just break their
> file descriptors. If in doubt, you have to exit or kill the program
> anyway.

I don't actually propose to "just break their file descriptors". If I have
a process that is actively doing io on a file I want to atomically switch
to a different (dentry, inode) pair whilst releasing the old ones. 

(yes, Manfred I do remember your objections expressed yesterday but I
don't think that is fundamentally wrong - just adds some more work
checking the caching cases)

The new inode is allocated from the nullfs filesystem and a new dentry is
allocated and instantiated with this new inode. Ok, you could argue that
the userspace could have done a stat on the file and remembered i_ino and
now it is a different inode number (as suitable for nullfs which has
nothing to do with old inode number). But that argument is not valid
because any attempt to do stat() (or anything else) on this same fd will
result in EIO anyway so the app can't find out it was fooled.

Regards,
Tigran