lkml.org 
[lkml]   [1997]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.982 / U:1.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site