Subject: RE: regarding file REMOVE(NFSv4 Implementation)

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 1 May 2000 08:33:30 -0700

As I remember this being discussed, there were two
sorts of behavior that might normally be expected,
corrsponding (loosely) to UNIX and NT views of the
world.  Warning: Looking at the section 14.2.26 in
Draft 6, it seems a bit at variance with my memory
so one or the other (or both) may be wrong.

One thing that I think that servers may do with a
REMOVE while a file is open is to reject it as an
error.  Looking at section 14.2.26, this doesn't 
seem to be mentioned, and there is no obvious fit
for the error that such a server would return.

The other possible reasonable behavior is to do
the UNIX thing of removing the name but leaving 
the file itself with the deletion of space, etc,
waiting for the file to be closed, just as happens
with local access today.  Since we have OPEN and
CLOSE in the protocol, the server has the information
to do this, although there may be some interesting
implementation challenges doing this correctly 
across a server reboot.

The text of 14.2.26 is somewhat at variance with this,
but I am not exactly sure what it is telling the 
server implementor to do.  It says, "The concept of last 
reference is server specific".  OK, but a reference
by means of an open file, isn't really server-specific,
it is part of the protocol.  Then it says that if
the file had only one link before the REMOVE, the
client should not "rely on referring to the object
via file handle".  Hey, that's the way we refer 
to open fles in this protocol so it's kind of 
hard to avoid, unless you just don't do the REMOVE
in the first place.  It then makes reference to the 
V3 trick of doing a RENAME instead of a REMOVE.

The problem with this is that it can only deal with
a REMOVE done in the same client; the server is still
going to have to deal with a REMOVE done by another
client.  I guess it could make the handle STALE in
this case, and it appears that would be legal as
the spec stands, even if highly anti-social.  In
the case in which the open was on the same client,
nothing bad would happen, if the client used the
RENAME trick, as the spec indicates he should, so
the result would be no worse than V3 behavior, if
the server were just to make the handle STALE.

I guess I still don't see the need to keep the 
RENAME trick a part of the protocol, given that
we have OPEN and CLOSE, but it appears that it is.
Servers, are free however, to do the right thing,
for all REMOVES when the target file is open, even 
though the spec doesn't make them do so.

-----Original Message-----
From: kvs sivak [mailto:[email-masked]]
Sent: Monday, May 01, 2000 4:51 AM
To: [email-masked]
Subject: regarding file REMOVE(NFSv4 Implementation)

hi,
 regarding REMOVE oprn. on a NFS volume, consider the
scenario below:

   a process has opened file  "a", there by
establishing state at the server. Now if another
process wants to REMOVE file "a".
 what is the course of action when 
  1) Both the processes are on the same client .
       (The client will be able to determine that a  
        lock owner has established state for the file)
  2) The 2 processes reside on different clients.

 k.v.s
 k.siva

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

---

From: Carl Beame <[email-masked]>
Date: 02 May 2000 10:39:12 +0100

> implementation challenges doing this correctly 

Just a note that under NT, IF the user who opened the file for
"normal" manipulation allows FILE_SHARE_DELETE a second open can open
the file then set the file disposition to remove. When that file is
closed the name is removed from the directory and the file is removed
when all the remaining opens are closed.

- Carl