"John R. Vanderpool" <[EMAIL PROTECTED]> writes: >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.
There may be systems, which don't update the st_ctime field when renaming (see rename(2)) (not linking or unlinking) a file, which is permitted by the Single Unix Specification. Just comparing y's time to a's wouldn't be enough, since dir/a/x wouldn't be archived again after the mv command: set -x && \ rm -rf -- dir dir.tar dir.snapshot && \ mkdir -p -- dir/a && \ touch -- dir/a/w && \ touch -- dir/a/x && \ touch -- dir/a/y && \ tar -c -v -f dir.tar -g dir.snapshot -- ./dir/ && \ sleep 60 && \ rm -- dir/a/x && \ mv -- dir/a/w dir/a/x && \ tar -c -v -f dir.tar -g dir.snapshot -- ./dir/ && \ ls -lcd -- dir/a dir/a/* might produce the (hypothetical) output + rm -rf -- dir dir.tar dir.snapshot + mkdir -p -- dir/a + touch -- dir/a/w + touch -- dir/a/x + touch -- dir/a/y + tar -c -v -f dir.tar -g dir.snapshot -- ./dir/ tar: ./dir/a: Directory is new ./dir/ ./dir/a/ ./dir/a/w ./dir/a/x ./dir/a/y + sleep 60 + rm -- dir/a/x + mv -- dir/a/w dir/a/x + tar -c -v -f dir.tar -g dir.snapshot -- ./dir/ ./dir/ ./dir/a/ + ls -lcd -- dir/a dir/a/x dir/a/y drwxrwx--- 2 helmut helmut 8 2006-03-17T11:12:13+0100 dir/a -rw-rw---- 1 helmut helmut 0 2006-03-17T11:11:13+0100 dir/a/x -rw-rw---- 1 helmut helmut 0 2006-03-17T11:11:13+0100 dir/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. If tar compared './dir/a/x's time of last status change with './dir/a's time of last data modification it would not detect the necessity to archive './dir/a/x' again in order to reflect the change of its name. Can tar on a system, where renaming a file doesn't update its last status change time, detect, that './dir/a/x' must be archived again, whereas './dir/a/y' need not be archived again? -- Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with meinen Vor- und Nachnamen, etwa so: | my full name, like Helmut Waitzmann <[EMAIL PROTECTED]>, (Helmut Waitzmann) [EMAIL PROTECTED] _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
