>>My suspicion is that GNU tar, which I use in the version 1.12, somehow
>>cannot compute incrementals right, for filesystems of vfat type that
>>are mounted the way I described above...(?)
>Even RedHat have a later version of GNU tar than 1.1.2 and (honestly)
>they're not known to release the latest versions of programs. Upgrade
>tar to at least (GNU tar) 1.13.17; the ones below this are likely to
>cause all sorts of weird problems.
I'm using 1.13.17 and have the same problem: incrementals on vfat just
don't work, they're effectively the same as full backups. tar seems to
think that every file has been modified since the last backup.
Searches elsewhere suggest that it stems from a rewrite of the kernel
vfat support between kernels 2.10 and 2.11, but I couldn't find a
solution mentioned anywhere (*). It's very frustrating. If anyone else
has an idea what to do I'd be ecstatic: this added hours to my daily
incrementals until I just gave up on backing up Windows.
Conrad
* 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).
