[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [nfsv4] Asking for details about OPEN_DOWNGRADE
On Wed, 2008-06-25 at 16:51 -0400, Rick Macklem wrote:
> > The other user of DENY_* would be Microsoft machines. If you don't plan
> > to ever have your client run against a Windows-based server or work with
> > other Windows-based clients, then you are fine, but if not, you are
> > likely to be preventing the correct operation of many of their
> > applications.
> >
> Lost me here. I can see why a WIN32 API client would do DENY_*, but I
> don't see why having a server implemented under windows makes any
> difference. Ditto w.r.t. other Windows clients. If your POSIX client
> does DENY_WRITE, then another POSIX client won't be able to open the
> file for writing and that will confuse it. Ditto for POSIX clients w.r.t
> DENY_READ.
As stated earlier, there is absolutely a precedence for DENY_WRITE (viz
ETXTBSY) on posix systems.
As for Windows apps what matters isn't _why_ they should use DENY_*, but
the fact that they _do_. In fact, the default share mode when you create
a file is exclusive access (DENY_READ+DENY_WRITE).
http://msdn.microsoft.com/en-us/library/aa363874(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb540534(VS.85).aspx
and yes, Windows application writers do rely on this:
http://www.linuxforums.org/forum/linux-programming-scripting/117514-there-file-share-mode-linux.html
so by not downgrading your READ_WRITE share mode to READ (or WRITE), you
are creating situations where you unnecessarily impede access to those
applications that do specify the conflicting share mode of DENY_WRITE
(or DENY_READ).
To summarise: the problem is that you are holding on to a mandatory lock
after your application is done with it.
Trond
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4