[SAMBA4][PATCH] dd client for samba 4

[James Peach]

On Wed, 18 Jan 2006 10:44 am, Andrew Bartlett wrote:
> On Wed, 2006-01-18 at 10:12 +1100, James Peach wrote:
[snip]
> > The dd subcommand certainly wouldn't operate like any of the other smbclient
> > subcommands.

I would go further, and say that the only thing (cif)sdd has in common
with smbclient is that they both connect to an CIFS server. They have
entirely different purposes and audiences (and therefore different syntax
and implementation).

> Perhaps we need to change the syntax a bit more (then do any munging in
> a shell wrapper, to better match what you want in for your test harness)

I imagine that there are a lot of scripts out there that know how to
drive smbclient. I'm not sure that changing its syntax is a good idea.

> smbclient -c 'blockwrite <local> <remote> <options>'
> smbclient -c 'blockread <remote> <local> <options>'

Do you mean
	smbclient //server1/foo -c 'blockwrite <local> <remote> <options>'
	smbclient //server1/foo -c 'blockread <remote> <local> <options>'

Does <remote> refer to server1 a file on server1, or can it specify a
different server? What does this look like then I want to do
    cifsdd if=//server/foo/source of=//server1/foo/dest

The dd syntax above is unambigious. The block{read,write} syntax is
making my head hurt.

> The wrapper script can then pull apart which has the //server/share/
> prefix, and call the appropriate subcommand.

In this case, I have to maintain the blockwrite code path in smbclient
as well as the wrapper. This seems very likely to break.

> > Second, the smbclient syntax is incompatible with existing test harnesses that
> > drive dd. The usage I'm planning for this is something like:
> >     DD=/usr/samba/bin/sdd SRC=//server/share/foo DST=/dev/null ./test.sh
> > 
> > Third, the sdd command is carefully constructed to do exactly the IO
> > you tell it to as far as possible. If you specify a 32KiB block size,
> > then you get a 32KiB read on the wire. To move this code into smbclient
> > would require moving its IO path. smbclient would then contain 2 parallell
> > IO paths. I don't see how making smbclient more complicated in this way
> > is helpful.
> 
> smbcacls was a tool created to handle a particular task in Samba, and no
> doubt did that task quite well, without disrupting other tools.  It also
> broke very often, and was unmaintained and untested for long periods of
> time.  

If smbcacls bitrotted, that's because it was unmaintained and
unused. Obviously that is a risk for any piece of code irrespective of
its location in the source tree. Since I intend to use this tool, then
it's reasonable to assume it will continue to work. Adding a test for
it into "make test" will ensure that at least the basics will continue
to work in my absence.

Is the team position really that smbclient is the only client? How
do we intend to ensure that none of the 50 (and presumably growing)
subcommands in smbclient bitrots? I assume that people outside the team
are going to want to write CIFS clients for various reasons and that
this will be supported.

> The situation is better these days, particularly thanks to the popt,
> better documentation (magic includes of common options) and other
> tricks, but there is still a cost.
>
> I'm sorry to be so discouraging.

I'm less discouraged than puzzled. Shoving all sorts of unrelated gunk
into smbclient seems to me to be a recipe for producing unmaintainable
code. AFAICT the only objection is that separate commands are less
maintainable, but this is a straw man IMO.

> > > Why the change to popt.h?
> > 
> > There was a gcc warning; when returning const char * const, the second const
> > has no effect.
> 
> I would prefer to leave it intact.  That code is meant to be simply the
> imported popt project.  We should update it sometime.

ok.

-- 
James Peach | jpeach at sgi.com | SGI Australian Software Group
I don't speak for SGI.