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).
--
Thanks,
Steve
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.
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.
Good point!
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?
-- Jamie
On Tue, Dec 2, 2008 at 2:06 PM, Jamie Lokier <[email protected]> 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
On Tue, Dec 2, 2008 at 2:20 PM, Steve French <[email protected]> wrote:
> On Tue, Dec 2, 2008 at 2:06 PM, Jamie Lokier <[email protected]> wrote:
>> Andreas Dilger wrote:
>>
>>> 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.
A typo in my earlier post ... I meant ... I don't think (just) posix locking
(without also using O_DENYREAD) can be sufficient.
> 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
>
--
Thanks,
Steve
Steve French wrote:
> On Tue, Dec 2, 2008 at 2:06 PM, Jamie Lokier <[email protected]> wrote:
>> 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.).
The title of their proposal was "client"... as in not the local
filesystem, but the impression of what wine really wanted is
for local linux filesystems to implement these non-posix behaviors
so "wine apps can run just like on windows" on the local machine.
Thus the strong objection from everyone doing local filesystems.
Passing exclusive DENYREAD DENYWRITE DENYDELETE network
protocol flags from a linux client to a remote server
is an entirely different and IMO acceptible thing.
And AFAIK on unix the only local support would be by doing
a client-on-server loopback, where the server implements
these modes as best it can and you are only protected
against wine apps that are also inside the "share drive".
jim
On Tue, Dec 2, 2008 at 3:20 PM, jim owens <[email protected]> wrote:
> Steve French wrote:
>>
>> On Tue, Dec 2, 2008 at 2:06 PM, Jamie Lokier <[email protected]> wrote:
>>>
>>> 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.).
>
> The title of their proposal was "client"... as in not the local
> filesystem, but the impression of what wine really wanted is
> for local linux filesystems to implement these non-posix behaviors
> so "wine apps can run just like on windows" on the local machine.
>
> Thus the strong objection from everyone doing local filesystems.
>
> Passing exclusive DENYREAD DENYWRITE DENYDELETE network
> protocol flags from a linux client to a remote server
> is an entirely different and IMO acceptible thing.
>
> And AFAIK on unix the only local support would be by doing
> a client-on-server loopback, where the server implements
> these modes as best it can and you are only protected
> against wine apps that are also inside the "share drive".
Yes, I think that this is more important for network file systems not
local file systems (especially since NFSv4 and CIFS and SMB2 all
support these flags in the protocol definition). Since wine (or any
subsystem running on a single local linux system) can handle its own
locks between application instances, the main problem is that byte
range locks can't perfectly emulate the application semantics needed
when applications are running on two different "clients" (in this
case, one Wine/Linux, and one a Windows client) but mounted to the
same server
--
Thanks,
Steve
On Tue, Dec 02, 2008 at 12:38:20PM -0700, Andreas Dilger wrote:
> 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 :-).
Indeed. If these flags are added it should only be for network
filesystem access, it would be a real mess for local access.
I guess it makes sense for them to be the inverse of the Windows
CreateFile call FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE
as by default Linux clients would use all these bits for a normal
open.
Jeremy.