Here are some attempts at a solution that did not work:
I installed tar-1.13.18.tar.gz from GNU. I also installed the source rpm for the already installed version 1.12, (in SuSE this is in the packet base.spm) in order to be able to see (in the /usr/src/packages/SOURCES/.dif file) what values SuSE uses for prefix, exec_prefix etc. I used
CFLAGS='-Wall -O2 -pipe' ./configure --prefix=/usr --bindir=/bin make make install |
for the tar-1-13-18 installation. But the new tar did not solve my problem.
In a message, Conrad Hughes wrote:
If I understand correctly (and there's no guarantee that I do), the vfat change was to ensure that a file on a vfat FS would have the same inode number for the duration of a single mount; inodes need to be constructed in some manner on vfat because it doesn't actually have real inodes, and the previous mechanism meant that a file's inode wouldn't be constant (for example a rename would change it; this caused much gnashing of teeth among one crowd of people). This new mechanism means inodes are fixed for the duration of a mount, but if you umount and remount then you have no guarantee of continuity; this is now causing gnashing of teeth amoung another crowd. Since tar --listed-incremental seems to record inodes, it gets very confused if the machine umounts and mounts a vfat system between backups (as would inevitably be the case if you rebooted for example).
I had the same problem, since I reboot my machine at least once day, i.e. between backup runs. So my solution was to avoid the use of tar with the --listed-incremental=FILE option and using --incremental instead. To achieve this I had to change the file config/config.h near line 628, undefining
GNUTAR_LISTED_INCREMENTAL_DIR as shown below and recompile. #ifdef GNUTAR /* Used in sendbackup-gnutar.c */ /*#define GNUTAR_LISTED_INCREMENTAL_DIR "/usr/local/var/amanda/gnutar-lists"*/ #undef GNUTAR_LISTED_INCREMENTAL_DIR /* #undef ENABLE_GNUTAR_ATIME_PRESERVE */ #endif |
Still, there were days when I did not reboot and the incrementals on the vfat filesystems were unjustifiably large.
In config/config.h I did:
/* Changed by root. * I undefine GNUTAR_LISTED_INCREMENTAL_DIR, so that, * instead of --listed-incremental, the options --incremental and --newer * will be used in sendsize.c #define GNUTAR_LISTED_INCREMENTAL_DIR "/var/lib/amanda/gnutar-lists" */ #undef GNUTAR_LISTED_INCREMENTAL_DIR /* #undef ENABLE_GNUTAR_ATIME_PRESERVE */ #endif |
After recompiling, I had to:
cp /scsi/DynaMo/linux/amanda/amcleanup /usr/bin/amcleanup cp /scsi/DynaMo/linux/amanda/amandates /etc/amandates |
John R. Jackson pointed out:
I think (but am not 100% certain) you can do this when you ./configure by adding --without-gnutar-listdir. Make sure you do a "make distclean" before re-running ./configure. Check config/config.h for GNUTAR_LISTED_INCREMENTAL_DIR after running ./configure to see if it's defined or not for this (re)build.
He is right - but I didn't do it that way. Anyway, it does not work! Look what happens to /dos/f, which was fully backed up the day before:
sendsize: getting size via gnutar for /dos/f level 0 sendsize: running "/usr/lib/amanda/runtar --create --directory /dos/f --incremental --newer 1970-01-01 0:00:00 GMT --sparse --one-file-system --ignore-failed-read --totals --file /dev/null ." Total bytes written: 220958720 (211MB, 8.8MB/s) ..... sendsize: getting size via gnutar for /dos/f level 1 sendsize: running "/usr/lib/amanda/runtar --create --directory /dos/f --incremental --newer 2000-12-06 4:36:16 GMT --sparse --one-file-system --ignore-failed-read --totals --file /dev/null ." Total bytes written: 194088960 (185MB, 14MB/s) |
And:
got result for host bacchus disk /dos/f: 0 -> 215780K, 1 -> 189540K, -1 -> -1K |
It is as if almost all of /dos/f changed in just one day (from Dec. 6th to Dec. 7th)! But f was not touched at all!
I decided to look at the ctime of a directory in /dos/f (with ll -c):
/dos/f/original/adaptec/other: total 1064 -rwxrwxr-x 1 chris windows 74649 Feb 9 2035 1542ccfg.exe -rwxrwxr-x 1 chris windows 288433 Feb 9 2035 aspi32.exe -rwxrwxr-x 1 chris windows 115200 Feb 9 2035 aspichk.exe -rwxrwxr-x 1 chris windows 49654 Feb 9 2035 cf154x.exe -rwxrwxr-x 1 chris windows 536645 Feb 9 2035 dosdrvr.exe drwxrwxr-x 2 chris windows 4096 Dec 30 1979 . drwxrwxr-x 7 chris windows 4096 Dec 30 1979 .. |
See this? Somehow the ctime has been set to a date in 2035 and since this is definitely bigger than any current date, --newer will not work.There are 2 solutions to this:
Change the ctime to something more usable.
Use --newer-mtime (see below).