> Linus Torvalds wrote:
> > The problem is that "sillyrename_cleanup" has nothing to do with the
> > inode. It depends _only_ on the 'dentry'. The inode may be around
> > (indefinitely) with a non-zero count for hardlinks etc..
> > This is why I haven't applied Claus-Justus' patches: they tried to handle
> > this, but I don't like the way it was done. I think we should just add a
> > "delete" (or "forget") function to the "dentry_operations" structure
> > block, and call that from dput() when we put the last copy of the dentry.
> > Then the NFS code would delete the silly rename where it is appropriate,
> > without any hacks (no need to remove the dentry from the hash chains etc
> > like Claus did).
> I thought silly rename was generally used only to support temp files
> with nlink = 1.
> If the sillyrename is handled at the dentry level, doesn't that also
> imply that the state associated with the rename will also need to be
> stored at the dentry? If the inode has nlink > 1, it might undergo
> silly renames in other directories where it appears, and need separate
> state for those.
Yes! Yes! Yes! This is actually needed, really. And I think that my
current hack actually handles thoses cases: it permits for one temp
file in EACH directory the inode ever gets linked into.
As Linus states, with 2.1 the silly rename stuff must be handled at
the dcache level. With 2.0, the i_count gave the number of users of an
inode. With the new dcache code, however, i_count simply flags that
the inode is used at all. It even might not be used at all, but only
be kept by a dentry on the unused list.
Also, i_nlink is even worse: the NFS client implementation gets
i_nlink from the server. While hacking 2.1 NFS I tried to fake the
nlink count to be zero for silly renamed files that have no name entry
in any other directory. But it was REALLY ugly. I'd rather go with Linus:
* one needs to be able to do a silly rename in EACH directory that has
a name instance referring to that inode. This is needed for cross
directory hardlinke and even for moving files to other directories,
as the Linux user land nfsd creates different NFS file handles for
the moved (i.e. renamed) instance of the same inode. There is
already a comment of Olaf Kirch at the top of the plain 2.1 NFS
client code's nfs_rename() function that suggests how to handle it
(I tried to implement it and it works, though it might be ugly)
* Hiding the ".nfs#ino" files at all would be really a pain. But
keeping them and making them visible on the client machine makes it
necessary to handle those cases where a dentry with d_count == 0 is
put on the unused list. The current silly rename stuff makes it
necessary to struggle with the hash list of the parent dir. Linus'
suggestion seems to be better.