[PATCH] switch smbcli_open over to NTCreateAndX
jamespeach at me.com
Wed Jul 28 16:21:28 MDT 2010
On Jul 28, 2010, at 2:48 PM, Volker Lendecke wrote:
> On Wed, Jul 28, 2010 at 01:11:32PM -0700, James Peach wrote:
>> Yes, there's definitely valid arguments in both directions.
> I gave my arguments, I would like to hear the argument to
> stop using old calls, except to be compatible with NetApp :-)
But that is exactly my argument - for compatibility with servers that aren't Samba, and don't go to great lengths to implement calls that "real client" don't use.
> For example, if you run thunderbird on Linux using cifsfs
> against a NetApp filer, it can corrupt your mailboxes. The
> reason is that NetApp does not support the variant of
> ftruncate that cifsfs uses properly and cifsfs also does not
> properly retry with a different version. Then somewhere on
> the path into thunderbird the error code is lost, I've
> forgotten exactly where that got lost. The end result is
> that thunderbird under certain circumstances believes that
> it has truncated a mbox file while it has not. Another
> instance is cifsfs trying to list xattrs against NetApp.
> A version of NetApp that I've seen sent complete garbage. 39
> bytes of seemingly uninitialized memory. cifsfs did not
> appreciate that.
> It is a nice stream of income for me to diagnose those
> problems, but if possible I would like to avoid that
> behaviour on the Samba server side. That's why I would like
> to continue walking as many code paths as possible in our
> default test suite, insufficient as it might be currently.
>> In general, I'm arguing that the default operation for
>> smbtorture should be to use the modern protocol. That is,
>> if the test author did not go to the trouble of
>> deliberately specifying which operation to use, then it
>> should use NT LM 0.12.
> Just for my understanding: NT LM 0.12, doesn't that also
> include the old calls? If I remember correctly, the old
> documents said something about additional calls with every
> new release. But I might really be wrong here.
You are correct in that new dialects generally include support for the old dialects. However, MS-CIFS claims that command codes can be deprecated and the table in section 18.104.22.168 lists SMB_COM_OPEN_ANDX as deprecated. In section 1.7 on versioning, it comments that "deprecated [commands] are likely to become obsolete and are not recommended to be used by clients, even though it is recommended that servers support them". This seems like reasonable advice.
>> OK, I will hold off until I get a chance to add an
>> explicit SMBOpenAndX test. I'll post for review before
More information about the samba-technical