Re: [Bug-tar] tar creates invalid archives when files shrink during reading

[Frank Heckenbach]

> Frank Heckenbach <address@hidden> wrote:
> 
> > The following patch seems to fix the problem since `bufsize', not
> > `count' is used in the following `set_next_block_after' call.
> 
> Not quite so. The correct way would be:
> 
> Index: src/create.c
> ===================================================================
> RCS file: /cvsroot/tar/tar/src/create.c,v
> retrieving revision 1.94
> diff -p -u -r1.94 create.c
> --- src/create.c      7 Apr 2005 17:27:07 -0000       1.94
> +++ src/create.c      10 May 2005 14:24:46 -0000
> @@ -886,8 +886,6 @@ dump_regular_file (int fd, struct tar_st
>       }
>        size_left -= count;
>  
> -      set_next_block_after (blk + (bufsize - 1) / BLOCKSIZE);
> -
>        if (count != bufsize)
>       {
>         char buf[UINTMAX_STRSIZE_BOUND];
> @@ -903,6 +901,8 @@ dump_regular_file (int fd, struct tar_st
>         pad_archive (size_left);
>         return dump_status_short;
>       }
> +
> +      set_next_block_after (blk + (bufsize - 1) / BLOCKSIZE);
>      }
>    return dump_status_ok;
>  }

This seems to work for the /sys case, but not for other cases with
larger files. It's a bit hard to reproduce. This code reproduces a
problem rather reliably on my system:

#!/bin/sh
rm -f foo bar
echo dummy > baz
dd if=/dev/zero of=foo bs=1k seek=500000 count=1
(sleep 4; dd if=/dev/null of=foo bs=1k seek=499995 count=0) &
src/tar cf bar foo baz
src/tar tf bar

AFAICS, if you do it your way, you also need to move the

      size_left -= count;

after the `if', otherwise it does to *little* padding then.

Frank

-- 
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)