smbclient and clitar changes for proper tar handling
Luke Kenneth Casson Leighton
lkcl at switchboard.net
Sat Apr 4 16:21:42 GMT 1998
richard,
if you are going to make significant changes to smbclient, can you please
also make parallel updates in BRANCH_NTDOM? there are various noises to
use smbclient from BRANCH_NTDOM in the next alpha release. that task /
possibility is made difficult / more remote if smbclient goes too far out.
you should only find one global variables in BRANCH_NTDOM's smbclient:
struct client_state smb_cli. all the static variables in clitar.c and
client.c have been moved into a single structure.
luke
On Sat, 4 Apr 1998, Richard Sharpe wrote:
> Hi folks,
>
> I have had to modify dir_action and do_dir and do_long_dir in client.c to
> include the ability to process directories as well as files in directories.
> I have set the processing of directories off in all existing calls in
> client.c.
>
> This is needed for the following reason:
>
> When clitar.c writes a directory path to the tar file, it needs to write all
> the directory entries along the way as separate tar headers (type = '5') so
> we can get the creation dates in the tar file, so we can create the
> directories on restore with the correct creation dates! So there :-)
>
> Thus, clitar.c requests that directories be handed to the function (fn) as
> well as the contents of directories, while all existing calls to do_dir
> simply say no to directories (TM :-)
>
> So, clitar now writes directory headers into the tar file.
>
> Now that I have clitar seemingly writing correct tar files, I am going to
> work more on the restore part. This involves limited changes, including
> making a setatr call on each directory created to set the creation date.
>
> Can anyone comment on whether or not SMB/Samba/NT/etc allow the creation
> dates of a directory to be modified?
>
> Also, I will be restructuring the code in do_tarput so that it handles
> blocking properly. Something along the lines of:
>
> int nextblock( ...)
> {
> bufferp += TBLOCK;
> if (bufferp >= tarbuf + endorbuffer) {
> gets next block from the file/tape and sticks it in the buffer
> passed as arguments (a little like GNUtar);
> bufferp = tarbuf;
> }
>
> }
>
> int do_tarput( ...)
> {
>
> tarbuf = malloc(a shit load of space)
> bufferp = tarbuf + endofbuffer;
> while (true) {
>
> if (nextblock( ...) < 0){
> complain(short tar file, bummer);
> return 0;
> }
> switch (readtarheader( ...)) {
>
> CASE file:
> process_file();
> break;
>
> CASE longlink:
> process_longlink();
> break;
>
> CASE dir:
> process_dir();
> break;
> }
> }
>
> }
>
> Any comments?
>
>
> Regards
> -------
> 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,
> Linux, AIX, Digital UNIX, ULTRIX, SunOS, Samba, Apache, NetScape, ICSS,
> Perl, C, C++ ...
>
<a href="mailto:lkcl at samba.anu.edu.au" > Luke Kenneth Casson Leighton </a>
<a href="http://mailhost.cb1.com/~lkcl"> Samba and Network Development </a>
<a href="http://www.samba.co.uk" > Samba and Network Consultancy </a>
More information about the samba-technical
mailing list