Messages in this thread | | | Date | Fri, 22 Aug 1997 10:27:03 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: attempt to re-implement sillyrename for NFS in 2.1.* |
| |
On Fri, 22 Aug 1997, Bill Hawes wrote: > > I thought silly rename was generally used only to support temp files > with nlink = 1.
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
| |