Subject: attributes of renamed file

From: David Mazieres <[email-masked]>
Date: Mon, 6 Mar 2000 17:26:46 -0500 (EST)

It would be extremely useful if NFS4 servers could, after a RENAME
operation, atomically return the file handle and change_info4 of the
file actually being renamed.  In many implementations the server will
already have this information handy.  The client could use this
information to invalidate cached attributes without exposing itself to
a race condition as it must currently do.

David

---

From: Mike Eisler <[email-masked]>
Date: Mon, 6 Mar 2000 15:04:43 -0800 (PST)

> a race condition as it must currently do.

Could you describe the race condition? The NFSv3 RENAME procedure didn't
include the equivalent of change_info4 on the target file, just from source and target directories?

If the client has never cached any data on the file being renamed, why should
client and network be forced to bear the burden of extraneous information?

If the information is handy, COMPOUND can be used to get it.

	-mre

---

From: David Mazieres <[email-masked]>
Date: Mon, 6 Mar 2000 18:16:06 -0500 (EST)

> Date: Mon, 6 Mar 2000 15:04:43 -0800 (PST)
> From: Mike Eisler <[email-masked]>
> 

Is a COMPOUND operation atomic?  Suppose the client renames a file and
then does a LOOKUP.  If someone else gets in there and renames the
file again, the client will end up thinking it renamed the wrong
file.

Suppose the client is caching the attributes for file A, and then
RENAMEs file A but thinks it renamed file B (because of a non-atomic
compound operation).  If it doesn't flush the attributes for file A,
it may return the wrong ctime in a stat system call.

This can actually be pretty annoying in applications that rename a
file then stat it.  If they get a stale ctime, the next time they stat
the file they will think it has changed, even though it hasn't changed
since the rename.

David

---

From: Mike Eisler <[email-masked]>
Date: Mon, 6 Mar 2000 15:46:00 -0800 (PST)

> it may return the wrong ctime in a stat system call.

If the server indicates the file handle is volatile through RENAMEs, then the
the client shouldn't be caching attributes over a RENAME. If the file handle is
not volatile through a RENAME, then I don't see the problem.

> the file they will think it has changed, even though it hasn't changed

The above applies to a local file system. Such applications
had better cache inode# information before the rename.

	-mre

---

From: David Mazieres <[email-masked]>
Date: Mon, 6 Mar 2000 23:03:22 -0500 (EST)

> Date: Mon, 6 Mar 2000 15:46:00 -0800 (PST)

Sorry, this is not what I meant.  Suppose file handles are not
volatile.  The issue is knowing which file handle you actually
modified the ctime of.  Otherwise, in order to be completely correct,
you would need to flush all your cached attributes whenever you
renamed any file (because for all you know you could have renamed any
file).

One possibility would be to make the current file handle into the file
handle of the renamed file.  This information will almost certainly be
readily available to the server (since it has to update the attributes
of the renamed file).

> had better cache inode# information before the rename.

It's not an issue in the local file system, because the local file
system knows which file it has renamed.  Thus, it never lets status
information get out of date.

Here is an example of code that could behave incorrectly if the client
didn't figure out which file handle it renamed.  Imagine a text editor
like emacs that performs the following series of system calls:

     fd = open (".#foo#", ...)
     write (fd, ...);
     fsync (fd);
     rename (".#foo#", "foo");
     fstat (fd, &sb);
     close (fd);

Then, when the user next goes to write the file out:

     stat ("foo", &sb2);
     if (sb.st_ino != sb2.st_ino || sb.st_mtime != sb2.st_mtime || ...)
         || sb.st_ctime != sb2.st_ctime || ...)
       warn ("File has been modified.  Really save?");

If the client doesn't know which file handle it has renamed, it will
not flush the attribute cache for that file handle.  Thus, the fstat
call will then return the wrong ctime for the file (the ctime before
the rename), and text editor will incorrectly print this warning
message (assuming by then the attribute cache has timed out).

David

---

From: Brent <[email-masked]>
Date: Tue, 07 Mar 2000 00:59:30 -0800

> message (assuming by then the attribute cache has timed out).

Like Mike, I can't see a confusion problem here.  

If the client manipulates the file through its filehandle, or
in the example, through its file descriptor, then the renames
have no effect on the file contents or attributes.  The file
name is completely independent of the file content or attributes.

If the client app needs a stable reference to the file content (as in
the case of a text editor) then to be independent of renames, it must
reference the file through its file descriptor.

If the client app chooses to use the file name as a reference, then
there's a risk the name will change unexpectedly.

	Brent

---

From: David Mazieres <[email-masked]>
Date: Tue, 7 Mar 2000 08:16:03 -0500 (EST)

> Date: Tue, 07 Mar 2000 00:59:30 -0800
> From: Brent <[email-masked]>
> 

Not so in most Unix file systems.  Changing the file's name changes
the ctime.  Since a bumped ctime may also be a sign of someone
manually fiddling with the mtime, applications may react to this.

> reference the file through its file descriptor.

I agree.  However, as a rule, when the the client manipulates a file
by name, it is useful to tell it what file it has actually manipulated
so that it can keep its attribute cache in order.

To take another approach, consider, by analogy, the CREATE operation.
CREATE sets (chf) to the file handle of the newly created object,
presumably so the client can do a GETFH and find out what it just
created.  You could have left (cfh) as the parent directory, arguing
"just append a LOOKUP to the CREATE with COMPOUND", but this would
have opened a race condition since the compound is not atomic.

With RENAME, it's also important to know what file you are
renaming--so you can flush it from the attribute cache (or, better
yet, GETATTR it in a COMPOUND).

> there's a risk the name will change unexpectedly.

No argument about that.  The problem is using the file handle as a
reference (through a file descriptor), simultaneously manipulating the
file through its name, and in the end not realizing the file you just
manipulated corresponds to the file handle.

David

---

From: Michael Salmon <[email-masked]>
Date: Tue, 07 Mar 2000 16:05:06 +0100

> manually fiddling with the mtime, applications may react to this.

The ctime is only updated when the inode changes and the file's name is not
coupled to the inode. File names only exist in directories, a file doesn't
even need to have a name.

/Michael
-- 
This space intentionally left non-blank.

---

From: David Mazieres <[email-masked]>
Date: Tue, 7 Mar 2000 10:16:30 -0500 (EST)

> Date: Tue, 07 Mar 2000 16:05:06 +0100
> From: Michael Salmon <[email-masked]>
> 

Perhaps in part for historical reasons (since rename used to be a
non-atomic link and unlink), rename bumps the ctime of a file.  It
would be very difficult to do things like incremental backups of a
directory without this feature, however, so I think it's not a bad
thing.

More concretely, though, I just tried this out on a solaris box, and
rename definitely bumps the ctime of a file, whether or not you agree
with the behavior.  It has been my experience that all Unixes do this.

David

---

From: Mike Eisler <[email-masked]>
Date: Tue, 7 Mar 2000 07:19:21 -0800 (PST)

> > If the server indicates the file handle is volatile through RENAMEs, then
> the > the client shouldn't be caching attributes over a RENAME. If the file
> handle is > not volatile through a RENAME, then I don't see the problem.

Sorry, I'm just not getting it. The issue, whatever it is, is no
different from NFSv2 and NFSv3, and I don't know of any ctime problems
with RENAME.

> not flush the attribute cache for that file handle. 

The client that supposedly doesn't know which file handle has been "renamed"
(the file handle doesn't change btw), is the one that did the rename. 
The client thus knows to flush its attributes.

> even need to have a name.

You would think. However I just ran a quick test on a local file system, and
saw that rename did change the ctime.

	-mre

---

From: David Mazieres <[email-masked]>
Date: Tue, 7 Mar 2000 10:21:55 -0500 (EST)

> Date: Tue, 7 Mar 2000 07:19:21 -0800 (PST)

Actually this was a problem in older NFSes to.  I got badly burned by
this.  Obviously I make somewhat "unusual" use of the file system that
I don't expect you guys to sympathize with.  Nonetheless the race is
present in previous versions of NFS.

> The client thus knows to flush its attributes.

No, because there is a race condition.  If no one else touches the
file system, the client knows what file it has renamed.  If another
user changes things around at just the right time, howeve, the rename
will actually apply to another file.

David

---

From: Mike Eisler <[email-masked]>
Date: Tue, 7 Mar 2000 07:31:04 -0800 (PST)

> > The client that supposedly doesn't know which file handle has been
> "renamed" > (the file handle doesn't change btw), is the one that did the
> rename.  > The client thus knows to flush its attributes.
> 

Sorry, I guess I'm dense, but I don't see what problem you are trying to
solve, and how adding an a ctime to the results of the of
REANME will solve it. 

	-mre