From: Sergey Klyushin (Sergey.Klyushin@hummingbird.com)
Date: 09/24/01-01:07:37 PM Z
From: "Sergey Klyushin" <Sergey.Klyushin@hummingbird.com>
Subject: RE: Issues list for RFC3010
Date: Mon, 24 Sep 2001 14:07:37 -0400
Message-ID: <GGEOLDPPPFAMIJEOBJIBKEFNDBAA.Sergey.Klyushin@hummingbird.com>
Here is how OpenFile/CreateFile works on Windows (locally):
1. OpenFile/CreateFile has one more share attribute FILE_SHARE_DELETE
1.1 If file is opened WITH FILE_SHARE_DELETE, than request from ANOTHER
application to REMOVE file will succeed.
File won't be removed immediately, but will be removed on the last CLOSE
request.
New OPENs will fail (with exception OPEN to DELETE).
File still will be listed in directory
Attempt to create file with the same name will fail.
1.2 If file is opened WITHOUT FILE_SHARE_DELETE, than request from ANOTHER
application to REMOVE file will FAIL.
2. OpenFile/CreateFile has lots of flags one of which is
FILE_FLAG_DELETE_ON_CLOSE (kind of intention OPEN,REMOVE,READ)
If this flag is specified at OPEN/CREATE, than file be deleted on last
CLOSE.
3. File has attribute DELETE_PENDING, that explains application why it could
not be OPENED other than for deleting.
I am trying to implement NFS as much close to local (Windows) OS as
possible, but some operations could not be
implemented. I understand that NFS protocol can't cover all OSs, but if we
could cover as much local OSs as possible,
we'll benefit it later.
Sergey
> -----Original Message-----
> From: Noveck, Dave [mailto:Dave.Noveck@netapp.com]
> Sent: Sunday, September 23, 2001 1:11 PM
> To: 'David Robinson'; nfsv4-wg@sunroof.eng.sun.com
> Subject: RE: Issues list for RFC3010
>
>
> This isn't exactly what you were asking about, but I think
> there is a case in which your approach would require some
> identification of who is doing the remove, at least to the
> clientid granularity.
>
> Consider a file which is opened by processes on two different
> clients, A and B. Now suppose A does a remove and the
> server does not support a delete on last close mechanism
> to it returns NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE.
> So client renames the file. Now the application on A
> does a close so it now removes the file. But the server
> knows that the file is open and would return that same
> NFS4ERR_NO_CAN_DO_USE_THE_OLD_HACK_PLEASE and the client
> has no way of dealing with that that since he has no way
> of knowing when the global last close will occur and, by
> hypothesis the server can't do the remove at the appropriate
> time either. And further there is no way for the client to
> force the remove immediately either.
>
> If the REMOVE had a clientid parameter, the server could only
> check opens for that client and return HACK_PLEASE only if
> the file were opened by that client. Then, in the example
> above, the file would actually get removed when it was closed
> by A, which would certainly annoy B, but is no worse than what
> happens now (i.e in V2 and V3).
>
> An alternative would be to pass a parameter flag that indicates
> this is a hack remove, this_is_the_hack_so_dont_ask_for_the_hack,
> which would also force an immediate remove in this situation,
> independent of any opens of the file, unless the server dupported
> delete on last close.
>
>
> -----Original Message-----
> From: David Robinson [mailto:David.Robinson@Sun.COM]
> Sent: Friday, September 21, 2001 6:06 PM
> To: nfsv4-wg@sunroof.eng.sun.com
> Subject: Re: Issues list for RFC3010
>
>
> > But you didn't address the issue when the server can support it but
> > only in cases that it knows that it is what the client
> wants. Suppose
> > we have a server (say the win2k server) that will disallow REMOVE of
> > an OPEN file in the general case. However, it has the underlying
> > capability to allow the client the OPEN, REMOVE, READ
> sequence. Your
> > proposal doesn't allow the client a method of determining that
> > capability. Maybe Sergey can let us know if this is what his server
> > might do?
>
> If I understand this correctly, the question is if there
> exists a server
> that will deny a REMOVE differently depending on if the caller was the
> one who OPENed the file or not. For example, you can only
> REMOVE an OPEN
> file if you OPENed it. Sergey, do you know of such a case? I don't.
>
> In any case I would advocate that the server can choose to REMOVE an
> OPEN file or not based on whatever criteria it wishes to use. But
> if it allows the REMOVE it MUST follow the failure semantics
> previously
> described.
>
> If someone does come up with a weird OS that would require us to
> use stateid's or other client state, I will advocate not allowing
> REMOVE of OPEN files.
>
> -David
>
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:10 AM Z CST