The Samba VFS and return values ...

[Richard Sharpe]

On Wed, Apr 15, 2015 at 1:10 AM, Volker Lendecke
<Volker.Lendecke at sernet.de> wrote:
> On Tue, Apr 14, 2015 at 09:48:21AM -0700, Richard Sharpe wrote:
>> Hi folks,
>>
>> I have long thought it would be good to have all Samba VFS functions
>> return NTSTATUS codes (without exception.)
>>
>> Why?
>>
>> 1. Consistency. Today some return ints (< 0 for error) and set errno,
>> some NTSTATUSes, some return pointers to objects and return NULL on
>> error and set errno.
>>
>> 2. There have been times where I have wanted to return
>> NT_STATUS_SHARING_VIOLATION from the earliest VFS function Samba
>> returns, but could not because it did not return an NTSTATUS. In those
>> cases I was forced to add something like #define ESHARINGVIOLATION
>> 1001 and add translations to the various tables. This is ugly. I am
>> sure others have been in the same position.
>>
>> Last week I posted a patch that is my first attempt at this. I
>> converted realpath to returning an NTSTATUS result.
>>
>> This one is important because Samba calls SMB_VFS_REALPATH first for
>> every filename/pathname operation.
>>
>> The conversion was non-trivial because Samba is handling the error
>> codes in special ways for some cases (eg ENOTDIR and ENOENT) so I had
>> to make sure I preserved that.
>>
>> Stat is the next on on my list.
>>
>> However, before proceeding, I wanted to find out if anyone has any
>> objections or suggestions on how to better achieve my goal.
>>
>> My goal is that people who write VFS modules should be able to return
>> NT STATUS codes like STATUS_PATH_NO_COVERED, STATUS_SHARING_VIOLATION
>> etc rather than having to define bogus errno codes ...
>
> In particular with the SHARING_VIOLATION I have concerns. Nothing
> that can't be fixed, but our handling of SHARING_VIOLATION
> is really involved right now. There is a considerable engine
> around the 1-second delay for SMB1 sharing violation
> together with waiting for oplock breaks. This all needs
> complete overhaul, essentially open_file_ntcreate needs to
> become completely asynchronous using tevent_req. I know that
> it's unlikely to happen soon, as this is a major rewrite of
> one of our most complicated routines. But returning
> SHARING_VIOLATION in particular up our SMB1 stack can cause
> very bad consequences.
>
> Can you describe in more detail where exactly you want to
> return SHARING_VIOLATION and what effect you want this to
> have on the client request? What is the high-level
> requirement you have that Samba does not match fine now?

Ahhh, this is an important area I had not thought about.

I currently do not need to return SHARING_VIOLATION but we were doing
that at Panzura because we were running lots of separate instances of
Samba and pretending that they were one big NTFS thing.

Also, as I recall, the 1-second delay is only for SMB1?

In any event, your comments about an overhaul are relevant ... after
the merging of he create-file and create-directory paths, eh?

-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)