[linux-cifs-client] Re: POSIX Create/Mkdir and Create Action

[Steve French]

On Sat, 2007-03-10 at 00:32 -0800, James Peach wrote:
> On 09/03/2007, at 9:28 PM, Jeremy Allison wrote:
> 
> > On Fri, Mar 09, 2007 at 09:45:01PM -0600, Steve French wrote:
> >
> >> Don't we need one more thing in the POSIX Create/Mkdir/Open response?
> >
> > posix_mkdir returns EEXIST (or the NT_STATUS equivalent -
> > NT_STATUS_OBJECT_NAME_COLLISION) if the pathname already
> > existed, just like the system call.
> >
> >> In particular the CreateAction "FILE_CREATE" (not sure if the server
> >> ever returns FILE_SUPERSEDE).
> >>
> >> Are there CreateActions others that the client should care about?
> >>
> >> The client pays attention to whether the file was created or  
> >> opened e.g.
> >> when the user asks us to overwrite the inodes default uid/gid with  
> >> our
> >> default uid/gid (although not the default mount option - it is  
> >> allowed)
> >> we need to know if the file is new.
> >
> > I didn't know you needed to know that on posix_open.
> > If you need that info you need to change the spec,
> > now, before anything goes into production.
> 
> I don't think I quite understand the proposal. Can you rephrase it?
> 
> --
> James Peach | jpeach at samba.org
> 

My proposal would be:

change

2 bytes  Flags field (oplock response field)
2 bytes  Network file handle (fid). Zero returned here for mkdir case. 
2 bytes  Reply Information level returned (see below) 
2 bytes  Pad (Must be zero)  
(sizeof reply information)  Reply information

to

2 bytes  Flags field (oplock response field)
2 bytes  Network file handle (fid). Zero returned here for mkdir case.
4 bytes  CreateAction (as in NTCreateX response, MBZ for mkdir?)
2 bytes  Reply Information level returned (see below) 
2 bytes  Pad (Must be zero)  
followed by (sizeof reply information)  unix info qpathinfo data