Treating share modes as advisory when set by Mac clients

[Frank Lahm]

Am 12. März 2012 23:08 schrieb Brian Campbell <lambda at editshare.com>:
> On Mon, Mar 12, 2012 at 3:59 PM, Volker Lendecke
> <Volker.Lendecke at sernet.de>wrote:
>
>> On Mon, Mar 12, 2012 at 03:27:01PM -0400, Brian Campbell wrote:
>> > I work on network attached storage for video editing. Our customers use
>> > both Mac and Windows workstations, and on the Mac, they generally use
>> > Thursby Software's DAVE as a client, as it works much better than the
>> > built-in smbfs on Mac OS X.
>> >
>> > On Mac OS X, when opening a file, you can request a shared or exclusive
>> > lock on the file using the O_SHLOCK or O_EXLOCK flags in the open() call.
>> > On local filesystems, these are implemented as locks with flock()
>> semantics.
>> >
>> > Thursby recently added support in DAVE to implement these flags using
>> share
>> > modes (DENY_WRITE/DENY_ALL). They apparently did this because Microsoft
>> > Word depends on these locks working, and was getting confused when two
>> > people could edit the same file at the same time. This also appears to be
>> > how smbfs on Mac OS X implements these open() flags.
>> >
>> > This has caused a problem for our customers using Final Cut (and possibly
>> > some other video editing software). When Final Cut writes files out in
>> > certain situations (renders, and log and transfer), it opens the file
>> with
>> > the O_EXLOCK flag, and holds the file open with that exclusive lock even
>> > after it's done writing, until you close out the entire project. Locally,
>> > that doesn't cause any problems, since the lock is advisory and most
>> > software that needs to read the file doesn't try to obtain any locks on
>> the
>> > file.
>>
>> My initial reaction is that it is a bug in Final Cut, but
>> that does not help you much now.
>
>
> Yeah, this seems like a bug in Final Cut to me. But Apple has killed Final
> Cut Pro 7 in favor of Final Cut Pro X, which is a completely different
> product which our customers don't use. We still need to support Final Cut
> Pro 7, even if Apple no longer does.
>
>
>> Does that behave in any way
>> differently if you store it on Windows servers? I can't
>> imagine that Final Cut can't be used when storing files
>> there. If Samba behaves differently, then we need
>> comparative network traces.
>>
>
> I have not tried this on Windows. I would expect it to work the same; I can
> try to find a Windows server to test against.
>
> In general, we try to support setups that aren't officially supported by
> the non-linear editors. For example, Avid generally refuses to write to
> network drives, but we convince it that it is writing to a local disk in
> order to get it to work. I believe that Final Cut also expects to be
> writing to a local disk or SAN, but one of our differentiating features is
> that we make NAS work for video editing which can make it a lot easier to
> quickly and seamlessly share media.
>
>
>> As an immediate relief, you might want to take a look at
>> "share modes = no". This is a per-share parameter which
>> makes Samba not use and respect share modes at all.
>
>
> As Jeremy mentions, this feature has bit-rotted, and when I did a quick
> test of it, it didn't fix the problem at all. We turned on "share modes =
> no" for a share, wrote to it with Final Cut, and when we tried opening it
> on a Windows machine with Final Cut open, it failed to be open, and
> smbstatus still reported that the file had share mode DENY_ALL.
>
>
>> You can
>> play similar tricks as mentioned in
>> https://wiki.samba.org/index.php/Client_specific_Log to
>> restrict the dangerous use to specific clients and specific
>> share.
>
>
> As a separate issue, in the past we've tried using similar tricks with %a
> to distinguish Mac from Windows clients. The problem is, %a reports "Vista"
> for DAVE, Mac OS X's smbfs, and Windows 7. It looks like set_remote_arch()
> in lib/util.c has an option for OSX, but reply_negprot() in smbd/negprot.c
> never uses that (and looks like a real hack based on the particular list of
> protocols the client reports support for).
>
> Would it be reasonable to add support for detecting Mac OS X and setting
> the remote arch to support this kind of trick, so that our customers don't
> have to maintain lists of which IPs run Mac OS X and which run Windows? I
> don't think that reply_negprot() is the right place to set this; it looks
> like much better information shows up in the NativeOS and NativeLanMan
> fields of the SESSION_SETUP_ANDX message.

I'd ask myself if I was asking the right questions. You're using a
Windows network protocol ducktaped for OS X. Hint: AFP.

-f