; a=shortlog; h=create_file_refactor

Jeremy Allison jra at
Mon Dec 1 17:53:40 GMT 2008

On Sun, Nov 30, 2008 at 10:04:59AM -0800, Tim Prouty wrote:
> On Nov 29, 2008, at 1:32 AM, Volker Lendecke wrote:
>> In general that looks very good, although I am a bit worried
>> about the implications of changing the direct callers of
>> open_file_ntcreate to create_file. open_file_ntcreate
>> assumes quite a bit of preprocessing like a unix path etc,
>> create_file does this again. It does survive make test for
>> me as well, but I'm not sure those code paths are really
>> covered by make test. For example, copy_internals, which
>> test does cover that?
>> Volker
> I introduced the new is_dos_path argument to the SMB_VFS_CREATE_FILE  
> interface to avoid calling unix_convert twice on a path.  All callers  
> that were previously calling open_file_ntcreate directly, pass in false, 
> which informs create_file that it should skip the unix_convert.  These 
> callers will go through more checks than they previously had, but most of 
> the checks are no-ops due to the arguments passed into 

Ok, hope I'm not too late on this. Rather than adding a
bool argument to the CREATE_FILE vfs interface, can we add
a uint32_t flags field instead and make is_dos_path a flag ?

The reason I'd like to do this is that I think that the
current method of overloading INTERNAL_OPEN_ONLY onto
the oplock_request field is a bad decision, and would
like to move that to a flags option.

We may also need another flag here to deal with the
oplock implications of opening a stream handle with
kernel oplocks.

Vl, Tim, what do you think ?


More information about the samba-technical mailing list