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

[Steve French]

On Tue, Dec 2, 2008 at 2:06 PM, Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote:
> Andreas Dilger wrote:
>> 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.
>
> It's a pain on Windows, yes.  It's necessary because you can't delete
> or rename over an open file (the unix way), so for files which must be
> updated without any program seeing them as temporarily corrup (.exe,
> .dll, config files, pid files, etc.) to do it on Windows is
> open-with-deny-read and write the new file contents.
>
>> 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.

I don't see how O_DENYREAD or more importantly, O_DENYWRITE can help.
If client A (Linux/Wine) does an open O_DENYWRITE, and we don't send
the O_DENYWRITE on open, Samba (or Windows or NetApp or random NAS
appliance etc.)
will allow the open even if another Windows client is writing to the
file.   The Linux/Wine
subsystem could try to do a posix byte range lock from byte 0 to end
of file and that
would get mapped by the cifs client to a mandatory lock, but it
doesn't help the case
where another Windows client already has the file open for write, and you expect
the open from your client to fail in that case.

> Is there any reason why Wine cannot take an advisory lock _every_ time
> it opens a file?  That would give Windows apps the behaviour they
> expect, including across the network, without DOSing unix apps.
>
>> 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.
>
> Windows apps do expect a file can't disappear while it's open.  This
> is one way to detect if an app is running, and this particular
> behaviour goes back to the oldest versions of Windows.
>
> Inside a single WINE instance or on a single host, your suggestion
> works, but what about Windows apps on different hosts over a network share?
>
> The bit I find interesting is that other CIFS clients are said to
> implement these flags.  If that means real unixes, maybe they've
> worked out a sensible way to handle them?

I thought that MacOS uses these flags (not just Windows, and of course
older clients too OS/2, DOS etc.).


-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/