Re: [Bug-tar] more on woes with --listed-incremental

[Helmut Waitzmann]

"John R. Vanderpool" <address@hidden> 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 <address@hidden>, (Helmut Waitzmann) address@hidden