> 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 0xFFFF 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 <metze at samba dot org>