talloc_tos in shadow_copy2_insert_string
clawsoon at yahoo.com
Thu Mar 29 08:31:29 MDT 2012
--- On Wed, 3/28/12, Jeremy Allison <jra at samba.org> wrote:
> Looks interesting. If you can get it cleaned up we'd be
> happy to move it into the main Samba source code (so
> long as it doesn't depend on any proprietary or other
> troublesome headers or APIs).
It's only pulling in Samba headers, so that shouldn't be a problem.
> Looks like it'll need a lot of work though, plus the
> shadow_copy modules are some of the most complex VFS
> modules, so you're not setting a low bar here :-).
Having the shadow_copy module as reference has been very helpful. I've been working on it for a couple of weeks, and I'd guess I'm about 80% there. (According to my project timeline calculator, that means I only have about 317% left to go. :-)
Yesterday I got it to work successfully against 3.6.3. Left to do:
- Torture test it (maybe with smbtorture? Investigate).
- Take a close look at the default functions for open, create_file, streaminfo, and closedir to make sure I know exactly what's going on under the hood and whether I need to do anything extra special with smb_fname/fsp before passing them along.
- Fix whatever's causing readdir to crash in my port to the latest git code. First two guesses: 1) The trick used by scannedonly and the original shadow_copy module to store extra information about an opened directory - casting between SMB_STRUCT_DIR and a custom struct - is no longer usable, or 2) some directories are now being opened without passing through opendir first.
- Double-check all fsp-using functions to make sure that fsp->fsp_name->base_name doesn't have to be munged before being passed to the next module. The fact that the scannedonly module does that in fdopendir makes me worry.
I think these are all doable, and I'll hopefully have something that works against the latest git sources Real Soon Now.
More information about the samba-technical