Bug 1748 - Smbclient -TN (back up files newer than) option fails
Smbclient -TN (back up files newer than) option fails
Status: RESOLVED INVALID
Product: Samba 3.0
Classification: Unclassified
Component: smbclient
3.0.6
Sparc Solaris
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-10 15:09 UTC by David S. Collier-Brown
Modified: 2007-08-19 09:38 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David S. Collier-Brown 2004-09-10 15:09:33 UTC
When tested on a Solaris 9 system, and on the Sun JDS (actually
SuSE) smbtar/smbclient back up all files rather than just the ones
newer than the file specified with the N option.

  I'm writing a draft article about Windows backup via smbclient/smbtar,
and discovered that the following does NOT work properly:

1) create a file with a recent date
$ touch smbtar_bydate.full.log
$ ls -l smbtar_bydate.full.log
-rw-r--r--   1 davecb   staff        132 Sep 10 10:36 smbtar_bydate.full.log
$ ls -lc smbtar_bydate.full.log
-rw-r--r--   1 davecb   staff        132 Sep 10 10:36 smbtar_bydate.full.log



2) Run smbtar spefifying -N smbtar_bydate.full.log
$ smbtar -a -N ./smbtar_bydate.full.log -s hobbes -x davecb \
        -u davecb -p <valid password> -i -t hobbes.backup.tar

3) smbtar runs the following smbclient command
$ smbclient '\hobbes\davecb' '<the password>' -U 'davecb' -E -d 2 -D '" -c
'tarmode inc' -TcagaN ./smbtar_bydate.full.log hobbes.backup.tar 

4) the tar file contains files older than September 10th:
$ tar tvf hobbes.backup.tar | head
drwxr-xr-x   0/0        0 Sep  8 10:01 2004 ./.dt/
drwxr-xr-x   0/0        0 Nov 17 10:17 2002 ./.dt/sessions/
drwxr-xr-x   0/0        0 Nov 17 10:17 2002 ./.dt/sessions/home/

Just in case the -a and -i options interefered I ran the smbtar
withouy them, and got the same result.


Inspection of 
/export/home/davecb/projects/samba/samba-3.0.6/source/client/clitar.c
shows what appears valid option-handling:
case 'N':
    if (Optind>=argc) {
        DEBUG(0,("Option N must be followed by valid file name\n"));
            return 0;
	} else {
            SMB_STRUCT_STAT stbuf;
            extern time_t newer_than;
            if (sys_stat(argv[Optind], &stbuf) == 0) {
                newer_than = stbuf.st_mtime;
                DEBUG(1,("Getting files newer than %s",
                    asctime(LocalTime(&newer_than))));

In client.c, newer_than is initialized to zero, and
is tested thusly, in a boolean function do_this_one.

static BOOL do_this_one(file_info *finfo)
    if (newer_than && finfo->mtime < newer_than) {
	DEBUG(3,("newer_than %s failed\n", finfo->name));
	return(False);
     }

do_this_one is called by do_list, display_finfo and do_du,
all of which look ok... but the results are the opposite
of what is expected!
Comment 1 David S. Collier-Brown 2004-09-11 07:11:42 UTC
In a subsequent test, I found that the files written to the ar file were
driectories or links: ordinary files older than the specified date did
not appear.  For example,
$ tar tvf foo | more
[...]
drwxr-xr-x   0/0        0 Apr 14 21:43 2004
./projects/Plugin/saved_tw_reports/copy_of_alcatel/explorer/bigboom/explorer.80d8a579.bigboom-2001.
----------   0/0      126 Dec 31 19:00 1969 ././@LongLink
drwxr-xr-x   0/0        0 Apr 14 22:03 2004
./projects/Plugin/saved_tw_reports/copy_of_alcatel/explorer/bigboom/explorer.80d8a579.bigboom-2001.
----------   0/0      128 Dec 31 19:00 1969 ././@LongLink

This implies that the date code is correct for "plain" files, but not 
direcories and symbolic links.
Comment 2 TAKAHASHI Motonobu 2005-02-16 10:40:34 UTC
For Samba 3.0.11 on Debian, the -TN option seems to work well:

monyo@mango:~/Work/Samba/smbldap-tools$ ls -l smbldap-tools-0.8.1.tgz
-rwxr--r--    1 monyo    users       51142 Jan 19 10:06 smbldap-tools-0.8.1.tgz
monyo@mango:~/Work/Samba/smbldap-tools$ smbclient -I 
192.168.135.1 //mayumi/temp -A ~/a -TcN smbldap-tools-0.8.1.tgz tako.tar
Getting files newer than Wed Jan 19 10:06:06 2005
Domain=[MAYUMI] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
                directory \a\
                directory \aaaa\
        2566 (  417.6 kb/s) \adminscript.vbs
(snip)
monyo@mango:~/Work/Samba/smbldap-tools$ tar tvf tako.tar
drwxr-xr-x 0/0               0 2005-01-16 17:58:14 ./a/
drwxr-xr-x 0/0               0 2005-01-06 03:03:45 ./aaaa/
-rw-r--r-- 0/0            2566 2005-02-03 02:11:41 ./adminscript.vbs
drwxr-xr-x 0/0               0 2005-01-06 03:03:50 ./archive/
(snio)
drwxr-xr-x 0/0               0 2005-01-06 03:04:00 ./err/Err/
-rw-r--r-- 0/0            1017 2005-02-03 02:13:17 ./listshares.vbs
drwxr-xr-x 0/0               0 2005-01-09 03:12:02 ./old/
(snip)
Comment 3 Gerald (Jerry) Carter 2005-02-17 08:06:23 UTC
david, could you test 3.0.11 on solaris and reopen if the 
bug still exists.  Thanks.
Comment 4 David S. Collier-Brown 2005-02-23 15:50:23 UTC
 The bnehavior reported by monyo@mango was the same as I
had observed: He reports
     Getting files newer than Wed Jan 19 10:06:06 2005
and
      drwxr-xr-x 0/0               0 2005-01-16 17:58:14 ./a/
and indeed, 16 Jan is older than 19 Jan...

  Question: is the backing up of directories
of whatever age a prerequisite for backing up
new file in those directories?
  If so, the bug is a lesser one, that unnecessary
directories and files are backed up.
Comment 5 David S. Collier-Brown 2007-08-19 09:38:33 UTC
I asked: is the backing up of directories of whatever age a
prerequisite for backing up new file in those directories?
  I'll answer my own question and say it can be with certain
older tar programs (notably an ancient one from Siemens).

  Therefor this is not a bug, and I'm closing it as invalid