bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug and fix for tar-1.13.17 - multi-volume with read-full-records or sma


From: Jan Bredereke
Subject: bug and fix for tar-1.13.17 - multi-volume with read-full-records or small block size
Date: Wed, 17 Jan 2001 19:13:00 +0100
User-agent: Mutt/1.2.5i

Dear tar maintainers,

I have discovered and fixed two bugs in tar-1.13.17 (from the
current SuSE 7.0 Linux edition). In this version, multiple volumes
do not work when used together with reading from a pipe, even when
using the option --read-full-records to handle short reads from a
pipe.

While fixing this bug, I found another one in the source code. It
occurs when using multiple volumes together with a block size of one
or two.

I attach a (GNU) makefile that demonstrates both problems. The
makefile creates the appropriate test data and then runs tar,
printing comments on what it is currently doing. See also the
comments at the beginning of the makefile.

Both bugs are in the source file src/buffer.c. The first bug is in
the function flush_read(). There is a handling for multi-volume, and
there is a handling for short reads due to reading from a pipe
(obeying the option --read-full-records). The latter handling jumps
to label short_read. But then the multi-volume handling is skipped,
so both features cannot be used together.

I have written a fix for the file src/buffer.c and attach a patch
for it. The fix introduces the function rmtread_full() and replaces
most, but not all, calls to rmtread() in buffer.c by rmtread_full().
This new function retries to read until it gets sufficient data,
when read_full_records_option is set, except at EOF.

While fixing this bug, I found that the function flush_read() does
not consider that a full record might be shorter than three blocks
(i.e., --blocking-factor=1 or 2). It therefore just reads one record
and then increments the block cursor up to two times, still
expecting data to be left. I fixed this by checking for the amount
of data left, when incrementing, and by performing more reads when
necessary. The makefile demonstrates this bug, too. With an unpatched
version of tar, the tar command crashes already when writing, since
the write code does not consider the above case, too. My patch fixes
both reading and writing.

Note: the reason to use pipes with multi-volume in the first place
was that tar does not stop reading immediately when the specified
length of the tape is exhausted. This lead to some ugly device
errors with my CD drive. Therefore I used dd to read the right
amount of data, and fed it into tar through a pipe.


I found also a third, minor problem with tar:
when running ./configure, the file lib/fnmatch.h is not created for
my platform, SuSE Linux (presumably correct, since the system
provides it). But in the makefile in the src directory, this file is
a prerequisite for several targets, nevertheless. Therefore I had to
create a symbolic link from the file lib/fnmatch.hno to
lib/fnmatch.h to let "make" run smoothly.

Regards,
Jan

-- 
Dr. Jan Bredereke
Email: address@hidden
(fwd'ed to: address@hidden, address@hidden)
WWW: http://www.tzi.de/~brederek                          PGP key available

Attachment: Makefile
Description: Text document

Attachment: tar-1.13.17patched.dif
Description: Text document

Attachment: pgpnJfFrzffVJ.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]