Re: [nfsv4] Asking for details about OPEN_DOWNGRADE

[Rick Macklem <rmacklem at uoguelph.ca>]

On Wed, 25 Jun 2008, Trond Myklebust wrote:

[stuff snipped]
> 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.
Ok, now I understand what you are referring to. I still don't believe it 
to be a likely problem, but I see your point.

Here's my view of it (assuming an open_owner4 granularity of a posix 
process):
1 - Few posix processes open the same file multiple times with different
    modes. Most will just open with whatever mode is needed and close when
    done. Some might open->close, open->close. (To be honest, a lot of
    posix processes don't even bother to do explicit closes and everything
    just gets closed upon exit().)
2 - For the rare posix process that does do open_for_reading,
    open_again_for_writing, close_for_writing, sometime later
    close_for_reading, what is the likelyhood that a Windows app running
    on a different client will want to open the file during the
    "sometime later" time period.

I just don't believe Windows apps will be sharing files with posix
apps running on different clients in this way, but I can see your
argument, rick.


_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4