> From: "Dr. Andreas Wehler" <[EMAIL PROTECTED]>
> Yes, I've experienced this too.
>
> : It won't dump core if file is smaller (say a few KB) or the option M
> : is not used.
>
...
> overlapping files are lost. Reading it back with "M"-option makes the
> first tape give a Segmentation fault at an offset of about 60MB. At
...
> and another distribution, but the same tar version "GNU tar 1.11.8".
...
> So, is this fault really ((tar-version) + data)-dependent? I usually
There is a buffer-overrun bug in (non-Debianized) tar-1.11.8 that involves
the -M flag. And yes, it is data dependent. The sensitization conditions
were:
- use of the --multi-volume option
- use of the --listed-incremental options
- a long file name (I think longer than the 100 character standard
(old?) tar limit)
- one other condition I can't remember; maybe just going to a
second volume
The symptoms I got were corruption of the data file for the --list-incremental
option. None of my data was corrupted, but an "incremental" backup wouldn't
be incremental. Francois Pinard said that others reported other symptoms.
Does anyone know if Debian patches this bug? (I'm sure it's fixed by now
in tar, but tar hasn't been released publically yet.) (If it's not
fixed in Debian, someone e-mail me, and I dig up and send you the
correction--a buffer that should have been sized with the _system_ maximum
pathname length was incorrectly declared with the standard _tar_ maximum
pathname length.)
Daniel
--
This message was delayed because the list mail delivery agent was down.
