Marek Kielar <[EMAIL PROTECTED]> 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
