Alexandre Oliva wrote:
I don't know how different it would be, but, if you eventually find
out it's too much, tell Amanda to use a wrapper script instead of GNU
tar in which you check whether the directory being backed up is in a
vfat filesystem, then replace the `--listed-incremental
On Dec 1, 2000, Chris Karakas [EMAIL PROTECTED] wrote:
Do you mean that just by undefining GNUTAR_LISTED_INCREMENTAL_DIR,
AMANDA is going to call tar using --incremental, instead of
--listed-incremental?
That's right.
And, by the way, what's the difference between the two?
The GNU tar
Chris Karakas wrote:
Consider the following situation: you try to minimize the Windows
footprint on your network. You migrate to Linux and SAMBA. Windows is
run only on the clients: all your data and applications are on the vfat
filesystems of the SAMBA server which runs Linux. Now you want
Andreas Herren wrote:
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
Conrad and David,
thank you very much for your replies. I upgraded to tar 1.13.18, but
even this newest version does not remedy the problem of incorrect
computation of incrementals on mounted vfat filesystems on my AMANDA
server.
I think the time of truth has come: AMANDA *cannot* backup
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
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
