Re: [Bug-tar] Wrong "size left" field value in chunk header in multi-volume

[Sergey Poznyakoff]

Marek Kielar <address@hidden> ha escrit:

> 1. I encountered a bug while making my own test using multi-volume - I
> provide a test case and I propose a solution at least for this case.

Thanks for reporting.  The proposed solution is incorrect, it breaks
several testcases.  I have installed a proper fix in the CVS.

> This leads tar executed with "-xf archive -ML 1"

Note that -L1 is possible only with -b2, otherwise tar will silently
set volume length to the record size.  This may be regarded as
misbehavior, so I fixed it to qualify this as a usage error. 

> 1.2. The cause
> The problem is caused by wrong value in real_s_sizeleft while writing
> the chunk header. For unknown reason to me this value is sometimes
> correct. 

The actual cause is flush_archive being called in the middle of buffer
switching, which happens only if volume length equals record size.

> 2. Other code
> 
> 2.1. Records_written are counted wrong (due to "wicked-way execution"
> - twice too often) in _gnu_flush_write and
> simple_flush_write. Proposed change.

Yes, I have installed this in CVS as well.

> 2.2. Copy_ptr and copy_size are calculated (logically) wrong - though
> it (un)fortunately does not make a change in execution. Proposed
> change.

They are calculated right. You seem to have misunderstood the code.

> 3.1.
> tar.c:
> Why DEFAULT_BLOCKING is made equal to 20? Should not it be 2, taking
> into consideration that "tape-length-size step" is 2*BLOCKSIZE? 

Please see the documentation, section 9.4.2 "The Blocking Factor of an
Archive" (available online at
http://www.gnu.org/software/tar/manual/html_node/Blocking-Factor.html).

> 3.3.
> buffer.c: flush_archive() . record_end variable
> What is the purpose of reassigning the same value to record_end, if it
> never changes without record_start, and here it is drawed from
> record_start.

Record_end  changes in plenty of places (lines 378,445,482,704, to name
a few).  The assignment may be superfluous here, but removing it would
require a thourough analysis of the workflow.

> 3.4.
> buffer.c: find_next_block() . hit_eof variable
> How does EOF-trapping work for (current_block == record_end), if in
> buffer.c: flush_archive() we have an assignment of "current_block =
> record_start" and current_block is never changed?

It is changed in set_next_block_after.

> 3.5.
> buffer.c: _gnu_flush_write() vs simple_flush_write()
> Why not incorporate a simple_flush_write() call into _gnu_flush_write()?

They serve different purposes.  The former is used only when the latter
is installed as a flush function, to avoid recursion.

> 3.6.
> I would say that there is an inconsequence in that space-indents and
> tab-indents are use simultaneously - tabs do not necessarily equal to
> 8 spaces.

Yes, you are right.

Regards,
Sergey