[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-tar] more on woes with --listed-incremental
From: |
John R. Vanderpool |
Subject: |
[Bug-tar] more on woes with --listed-incremental |
Date: |
Wed, 15 Mar 2006 16:16:20 -0500 (EST) |
> > also, what is the diff with the trailing slash here?:
>
> This is definitely a bug. Please try the attached patch. -sergey
cvs snapshot tar-1.15.2-20060210 w/ listed-incr trailing slash patch
at some point the --listed-incremental file went from having all the file
names in it to just the dirs (this is a good thing, as it is much smaller)
so for this method to work, i assume what gtar does is if it sees the
directory mtime changed, it then interogates all files in that dir to
see if their mtime (or, i would hope ctime?) is newer or equal to the
dir mtime; however, it appears this later stage is not working right,
here is a simple test to see:
# mkdir a
# touch a/x a/y
# gtar -c -v -f a.tar -g incrlis ./
gtar: ./a: Directory is new
./
./a/
gtar: ./a.tar: file is the archive; not dumped
./incrlis
./a/x
./a/y
# rm a/x
# gtar -c -v -f a.tar -g incrlis ./
./
./a/
gtar: ./a.tar: file is the archive; not dumped
./a/y
gtar puts a/y into the archive and it should not, it is doing it because
it saw dir a's time stamp changed, but then apparently not comparing
y's time to a's i guess.
this is greatly affecting us as we have directories with very large
amounts of data so if anything is added/removed/modified then we get
the whole dir in our incrementals and that is even filling up SDLT II
300GB tapes!
if i revert back to straight tar-1.15.2-20060210 the above simple example
does not do the wrong thing anymore; but, my large backups still exhibit
similar behavior (it backs up many files that have not changed)
- [Bug-tar] more on woes with --listed-incremental,
John R. Vanderpool <=