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!
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.
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)
david, could you test 3.0.11 on solaris and reopen if the bug still exists. Thanks.
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.
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