Re: Support for applications which need NFS or CIFS "share_deny" flags on open

[Andreas Dilger <adilger@sun.com>]

On Dec 02, 2008  10:31 -0600, Steve French wrote:
> Some of the Wine community posted last month to the cifs mailing list
> asking about a change needed for Wine for working properly over
> network mounts, but the change is not really cifs specific and would
> help other file systems as well so I wanted to mention it here.   The
> original post was:
> http://marc.info/?l=linux-cifs-client&m=122505569315992&w=2
> 
> Support for the flags they suggest would be easy for cifs (the
> protocol has a field for this, and cifs clients on various other OS
> set it), and should be fairly easy for NFSv4 (the RFC for NFSv4
> specifies the "share_deny" field within the NFS open request, and
> various clients, but not Linux, set it), and would allow WINE to
> function properly over a network mount.
> 
> >we proffer to add into the file /usr/include/asm-generic/fcntl.h
> > following flags:
> >
> >#define O_DENYREAD      004000000 /* Do not permit read access */
> >#define O_DENYWRITE     010000000 /* Do not permit write access */
> >#define O_DENYDELETE  020000000 /* Do not permit delete or rename
> > operations*/
> 
> Presumably for applications on local mounts, wine mediates their own
> mandatory locks, but this is impossible on network mounts without this
> change (and can lead to data corruption).

This is a disaster waiting to happen, and I would be against adding
such functionality to Linux.  It would allow userspace applications
to implement a denial of service to any file that they can open (e.g.
open("/lib/libc-2.7.so", O_DENYREAD) would be really bad :-).

It was always also a pain in the ass on Windows systems (back when I used
them) that backing up the filesystem would fail because something (app or
kernel) had files open in this mode and the backup tool couldn't even read
them to do the backup.  In some cases these files were opened very early
in boot and the only way to do a full backup was to boot from a separate
device and run the backup.  Not my idea of fun.

I can't see any reason for O_DENYREAD or O_DENYWRITE that can't be met
with existing file locking to maintain coherency if that is really needed.
As for O_DENYDELETE - wouldn't that be irrelevant if the WINE code keeps
an open file reference?  The data would still be accessible until WINE
exits, and it wouldn't be a DOS.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.