-----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-----