From: David Mazieres (dm@reeducation-labor.lcs.mit.edu)
Date: 03/07/00-07:16:03 AM Z
Date: Tue, 7 Mar 2000 08:16:03 -0500 (EST) Message-Id: <200003071316.IAA28900@reeducation-labor.lcs.mit.edu> From: David Mazieres <dm@reeducation-labor.lcs.mit.edu> Subject: Re: attributes of renamed file > Date: Tue, 07 Mar 2000 00:59:30 -0800 > From: Brent <brent@eng.sun.com> > > 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. 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. > 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. 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). > If the client app chooses to use the file name as a reference, then > 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
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:06 AM Z CST