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