The Samba VFS and return values ...

[Volker Lendecke]

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?

Thanks,

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de