Proposed new Unix POSIX_OPEN/POSIX_UNLINK calls.

James Peach jorgar at gmail.com
Wed Feb 7 00:46:41 GMT 2007


Just a couple of clarifications inline ...

On 06/02/07, Jeremy Allison <jra at samba.org> wrote:
> Here's the (initially coded) spec for the POSIX open and
> unlink calls.
>
> Server specifies it can serve these by returning :
>
> CIFS_UNIX_POSIX_PATH_OPERATIONS_CAP        0x20

So, this enables the new POSIX operations, but path name lookups
remain in the mode selected by CIFS_UNIX_POSIX_PATHNAMES_CAP. Correct?

> in the reply to a trans2 qfsinfo (TRANSACT2_QFSINFO 0x03)
> info level SMB_QUERY_CIFS_UNIX_INFO (0x200) call.
>
> For open, call TRANSACT2_SETPATHINFO (0x06) call
> info level :
>
> SMB_POSIX_PATH_OPEN            0x209
>
> The request data block should be 14 bytes consisting of
> the following :
>
> Size              Offset                  Value
> -----------------------------------------------
>
> 4 bytes           0            Flags field (same as smb_ntcreate_Flags
>                                in SMBNTCreateX to request oplocks).
> 4 bytes           4            POSIX open flags (see below).
> 4 bytes           8            POSIX mode_t (see below).
> 2 bytes          12            reply info level requested (see below).
>
> All values are little endian. Encodings are as follows :
>
> POSIX open flags :
> ------------------
>
> #define SMB_O_RDONLY                      0x1
> #define SMB_O_WRONLY                      0x2
> #define SMB_O_RDWR                        0x4
>
> #define SMB_O_CREAT                      0x10
> #define SMB_O_EXCL                       0x20
> #define SMB_O_TRUNC                      0x40
> #define SMB_O_APPEND                     0x80
> #define SMB_O_SYNC                      0x100
> #define SMB_O_DIRECTORY                 0x200
> #define SMB_O_NOFOLLOW                  0x400
> #define SMB_O_DIRECT                    0x800
>
> POSIX mode_t :
> --------------
>
> #define UNIX_X_OTH                      0000001
> #define UNIX_W_OTH                      0000002
> #define UNIX_R_OTH                      0000004
> #define UNIX_X_GRP                      0000010
> #define UNIX_W_GRP                      0000020
> #define UNIX_R_GRP                      0000040
> #define UNIX_X_USR                      0000100
> #define UNIX_W_USR                      0000200
> #define UNIX_R_USR                      0000400
> #define UNIX_STICKY                     0001000
> #define UNIX_SET_GID                    0002000
> #define UNIX_SET_UID                    0004000
>
> The reply info level is an optimization for clients,
> the server may not support this. The client requests

"might not", is better than "may not"

> the TRANSACT2_QUERYPATHINFO (0x05) info level it
> would like the server to return on the newly opened
> file. If it doesn't wish a response set these 2 bytes
> to zero. Currently the only valid info level requests
> here are SMB_QUERY_FILE_UNIX_BASIC (0x200) and
> SMB_SET_FILE_UNIX_INFO2 (0x20B, not yet defined).
>
> MKDIR call :
>
> To do the equivalent of a mkdir(path, mode) do the
> following request :
>
> flags: 0
> open flags: SMB_O_DIRECTORY|SMB_O_CREAT
> mode_t: Requested mode_t for the new directory.

This returns a file number of 0, and does not require a corresponding close.

Does this also (optionally) return the requested info level?

>
> The reply data block looks like the following
>
> Size              Offset                  Value
> -----------------------------------------------
> 1 byte           0                    oplock granted flags
>                                       (as returned by NTCreateX)
> 1 byte           1                    Must be Zero.
> 2 bytes          2                    Returned fnum.
> [2 - N bytes]    4                    Info level returned for the
>                                       opened file, or 0xFFFF if no
>                                       info level returned.
>
> For unlink, call TRANSACT2_SETPATHINFO (0x06) call
> info level :
>
> SMB_POSIX_PATH_UNLINK          0x20A
>
> No extra data is needed or returned.
>

nice!

-- 
James Peach | jorgar at gmail.com


More information about the samba-technical mailing list