Patch for smbclient command du, tar cn, PASSWD_FILE and
sharpe at ns.aus.com
Sun Sep 13 08:51:40 GMT 1998
Hi Alexandre and Jeremy,
At 03:06 AM 9/13/98 +1000, you wrote:
>Jeremy Allison <jallison at cthulhu.engr.sgi.com> writes:
>>> 1) create a new command, say, du, that will traverse the directory
>>> tree without printing anything but the total bytes. (preferred option)>
Yep - that sounds good to me.
>The attached patch implements the interactive command `du' for
>smbclient. It behaves *exactly* as dir, except that it won't print
>the directories and filenames as it traverses them.I have also implemented
the `n' switch for the `tar' interactive
>command, as well as for the command-line variant of it. I have chosen
>`n' because several Unix commands use the -n switch as a `do-nothing'
>(AKA `dry-run') request. BTW, dry_run will also be implicitly enabled
>when creating a tar-file to /dev/null. The speed-up is wonderful! :-)
>Anyway, I still feel annoyed about the way smbclient handles
>interactive tar invocations writing to stdout or reading from stdin.
>One of the problems is that it inconditionally closes tarhandle, which
>may cause it to close stdout and/or stdin when it should be requesting
>for more commands. The second problem is the fact that messages are
>printed to stdout by default, even if a tar-file is being created to
>it. IMO, if a tar-file is to be written to stdout, nothing else
>should, -E should be implicitly assumed. I'm pretty sure I've already
>submitted a patch that fixed this problem, quite a long time ago, but
>I no longer have a copy of it, because someone had told me the problem
>was fixed already, and I believed that. I may write it up again, if
>you'd agree on taking one more look at it. :-)
The problem with smbtar/clitar is that I introduced a bug when adding other
functionality to it, for which I apologise. I have seen several patches,
including one with Amanda, none of which fix the real problem, which was/is
a stupid printf in the code :-(
I have sent a correct patch to several people, and will make sure that the
correct patch gets intp the 2.0 source tree, but nothing is likely to get
into 1.9.18 now as we are no longer working on that three anymore I think.
All the patched you include below will be looked at when by me when
client.c has been restructured for 2.0. This will probably be done by me
>> How about support for PASSWD_FILE and/or PASSWD_FD?
>> Yes, a du and password file patch would be very welcome
>> and integrated into Samba 2.0 asap !With the attached patch, command line
>>overrides PASSWD_FD that
>overrides PASSWD_FILE that overrides PASSWD. PASSWD_FD expects a file
>descriptor number, and PASSWD_FILE, a file name. In the second case,
>the file will be opened for reading. In either case, at most 127
>bytes will be read (just like get_pass does), and anything after the
>first occurrence of a line-feed or a NUL (if they occur at all) is
>ignored. Empty passwords are reported as such; read errors are
>reported too. After the password is read, in the PASSWD_FILE case,
>the opened file is closed.
>mailto:oliva at dcc.unicamp.br mailto:aoliva at acm.org
>Universidade Estadual de Campinas, SP,
>Content-Type: application/octet-stream; type=patch
>Content-Disposition: attachment; filename="clitar.diff"
>Attachment Converted: "C:\docs\Eudora-recvd\clitar.diff"
Richard Sharpe, sharpe at ns.aus.com, NIC-Handle:RJS96
NS Computer Software and Services P/L,
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080,
Samba, Linux, Apache, Digital UNIX, AIX, Netscape, Stronghold, C, ...
More information about the samba-technical