Re: svn commit: samba r14173 - (fnum and smb_file change)
> Metze, > > > are you ok with r14256? > > The structures are definately better, but it seems to be failing quite > a few tests :-) > > for example, RAW-UNLINK is failing. I'm pretty sure it was this patch > that causes it, but I haven't worked out how yet. sorry, I take a look at it in about 5 hours, when I'm back from my exam... > > > the idea with this is that I'll later add struct ntvfs_handle *ntvfs to > > smb_handle, so that the ntvfs subsystem doesn't need to know about fnum > > or smb2_handle. > > oh, ok! So you'll have an idtree hanging off the session that maps the > fnum to the ntvfs_handle, then fill that in on calls that take a > handle? yep > The only slightly tricky bit will be calls that can take a 'wildcard' > handle. For example, SMBflush can take a handle of 0x meaning > "flush all open handles". We handle that in the backend at the moment. yes, I noticed yet, but I need to think a bit more about it. the simplest idea is to just move the for(each file) into the frontend, and call the backend for each file, but I hope I find a solution, where the cifs backend, can just pass one request. we have the same problem with smb_exit and smb_logoff... > Apart from that, I think this is a good idea. good:-) -- metze Stefan Metzmacher
Re: svn commit: samba r14173 - (fnum and smb_file change)
Metze, > are you ok with r14256? The structures are definately better, but it seems to be failing quite a few tests :-) for example, RAW-UNLINK is failing. I'm pretty sure it was this patch that causes it, but I haven't worked out how yet. > the idea with this is that I'll later add struct ntvfs_handle *ntvfs to > smb_handle, so that the ntvfs subsystem doesn't need to know about fnum > or smb2_handle. oh, ok! So you'll have an idtree hanging off the session that maps the fnum to the ntvfs_handle, then fill that in on calls that take a handle? The only slightly tricky bit will be calls that can take a 'wildcard' handle. For example, SMBflush can take a handle of 0x meaning "flush all open handles". We handle that in the backend at the moment. Apart from that, I think this is a good idea. Cheers, Tridge
Re: svn commit: samba r14173 - (fnum and smb_file change)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: > 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. Hi Tridge, are you ok with r14256? the idea with this is that I'll later add struct ntvfs_handle *ntvfs to smb_handle, so that the ntvfs subsystem doesn't need to know about fnum or smb2_handle. and as the handle allocation will be moved out of the modules to the main ntvfs context (this is needed for allowing multiple to allocate handles in the same id space). modules will call struct ntvfs_handle *ntvfs_handle_new(struct ntvfs_context *ctx); and the smb_server/smb/ smb_server/smb2/ code will act a bit like the current req_fnum() and will search the struct ntvfs_handle in the pool using the protocol specific key and then pass the ntvfs_handle to the backends. This makes it also easy possible to let multiple modules to hang private data on a file handle... metze -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEFKo9m70gjA5TCD8RAuAVAKDIS4qrAblBU+v/HTmlt2Ns8bef7QCeKj8n MautpL2A7V9JZxZuiAG1g1U= =lRn3 -END PGP SIGNATURE-
Re: svn commit: samba r14173 - (fnum and smb_file change)
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
