From: "Steve French" <smfrench@gmail.com>
To: "jim owens" <jowens@hp.com>
Cc: "Jamie Lokier" <jamie@shareable.org>,
"Andreas Dilger" <adilger@sun.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"linux-cifs-client@lists.samba.org"
<linux-cifs-client@lists.samba.org>
Subject: Re: Support for applications which need NFS or CIFS "share_deny" flags on open
Date: Tue, 2 Dec 2008 15:26:26 -0600 [thread overview]
Message-ID: <524f69650812021326w26ccceb3qb8d93283aca84558@mail.gmail.com> (raw)
In-Reply-To: <4935A692.3050300@hp.com>
On Tue, Dec 2, 2008 at 3:20 PM, jim owens <jowens@hp.com> wrote:
> Steve French wrote:
>>
>> On Tue, Dec 2, 2008 at 2:06 PM, Jamie Lokier <jamie@shareable.org> 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
next prev parent reply other threads:[~2008-12-02 21:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-02 16:31 Support for applications which need NFS or CIFS "share_deny" flags on open Steve French
2008-12-02 19:38 ` Andreas Dilger
2008-12-02 20:06 ` Jamie Lokier
2008-12-02 20:20 ` Steve French
2008-12-02 20:21 ` Steve French
2008-12-02 21:20 ` jim owens
2008-12-02 21:26 ` Steve French [this message]
2008-12-02 23:07 ` Jeremy Allison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524f69650812021326w26ccceb3qb8d93283aca84558@mail.gmail.com \
--to=smfrench@gmail.com \
--cc=adilger@sun.com \
--cc=jamie@shareable.org \
--cc=jowens@hp.com \
--cc=linux-cifs-client@lists.samba.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).