svn commit: samba r14173 - (fnum and smb_file change)

tridge at samba.org tridge at samba.org
Sat Mar 11 12:36:20 GMT 2006


Metze,

 > change smb interface structures to always use
 > a union smb_file, to abtract
 > - const char *path fot qpathinfo and setpathinfo
 > - uint16_t fnum for SMB
 > - smb2_handle handle for SMB2
 > 
 > the idea is to later add a struct ntvfs_handle *ntvfs
 > so that the ntvfs subsystem don't need to know the difference between SMB and SMB2

The change means that the purpose of in/out in our structures is
broken. For example, we now have file.fnum in the readx call, instead
of in.fnum. The structures are designed to be arranged so that all
input parameters are in xx.in.* and all output parameters are in
xx.out.*. That allows a user to quickly see what parameters are input
and what parameters are output, and also allows for auto-generation of
scripting interfaces. How will a generator know if the SMBreadx call
takes a file as input or output with the new interface?

The 2nd problem is that its now valid to set file.path for a readx
call, but readx call cannot take a pathname, so having a path name in
the union makes no sense. The only calls where the same structures are
used for both path and handled based calls are qfileinfo and
setfileinfo. I think you need a separate union for those (like we had
before) instead of making all functions take both a pathname and a
handle.

I'd much rather go back to the old structures, although it might be OK
to change "uint16_t fnum" to "smb_handle fnum", and make smb_handle be
a union of uint16 and a smb2_handle. I'm not certain that is a good
idea though, as the structures for the smb and smb2 calls are
distinct, so having a common file handle doesn't really seem to buy us
anything? Instead the ntvfs_generic layer could have a mapping
function between smb2_handle and uint16_t.

Cheers, Tridge


More information about the samba-cvs mailing list