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