That's the usual case, but it really has to work for linked files too.
> 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.
The whole silly-rename thing is a dentry-level operation, and doesn't
actually need to look at nlink at any point. The logic goes:
'inode->i_op->unlink()':
- look at "dentry->d_count": if it is > 1 we need to sillyrename,
because somebody has the file open still so we can't delete it
at the server.
- if dentry->d_count == 1, delete the file.
'dentry->d_op->delete()':
- look if we are silly-renamed (use "dentry->d_flag" for this, it's
usable for filesystem specific things). If so, do the actual NFS
server delete.
So at no point is "i_nlink" implicated.
Note that the silly-name can (and should) be shown in dentry->d_name (so
dentry->d_op->delete can just use the dentry name directly, and doesn't
necessarily even know about what the naming logic is). This allows silly
renaming to work even if the user has _moved_ the silly renamed file
(something that never worked with the old code - the silly rename stuff
just got terminally confused).
Linus