You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by bu...@apache.org on 2009/06/25 04:07:11 UTC
DO NOT REPLY [Bug 47421] New: tar task does not flush the buffer
correctly for a short block
https://issues.apache.org/bugzilla/show_bug.cgi?id=47421
Summary: tar task does not flush the buffer correctly for a
short block
Product: Ant
Version: 1.7.1
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Core tasks
AssignedTo: notifications@ant.apache.org
ReportedBy: gameldar@gmail.com
Created an attachment (id=23873)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23873)
patch to fix the writeBlock call to correctly account for the number of
records.
If the final block does not contain the full number of records that the buffer
supports then the resulting tar file contains the two EOF blocks (2 lots of 512
of nulls) followed by whatever was in the buffer previously. e.g. if the buffer
contains 3 blocks it would look like this in the final two blocks:
A
B
C
---
EOF
EOF
C
Looking through the code - in src/main/org/apache/tools/tar/TarBuffer.java the
process is normally as follows:
1. If the buffer is full then write out the block.
2. When writing out the block it always writes out the full blocksize
However when the close is called (or any call to flush) it will call the same
writeBlock method regardless of the number of records the buffer currently
contains.
The fix is simple - that when writing the block it should always calculate the
size to write out based upon the number of records and the record size. I've
attached a patch to fix this.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 47421] tar task does not flush the buffer
correctly for a short block
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47421
Stefan Bodewig <bo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Target Milestone|--- |1.8.0
--- Comment #2 from Stefan Bodewig <bo...@apache.org> 2009-06-29 21:27:10 PST ---
your patch would lead to tar archives whose last block was incomplete.
Following the comments in readBlock this may be what other archivers do as
well, but it seems to violate the specification (don't have any source for the
spec right now).
I think the cleaner approach would be to zero out the unused part of the block,
this could be done in writeBlock after the block has been written. This has
been done in svn revision 789556 ( https://svn.apache.org/viewcvs.cgi?view=rev&rev=789556 )
Could you please verify that this approach fixes the problem you see (my tar
implementations didn't have any problem with the old Ant code).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 47421] tar task does not flush the buffer
correctly for a short block
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47421
--- Comment #4 from Stefan Bodewig <bo...@apache.org> 2009-06-30 00:28:38 PST ---
Thanks Kirk,
I guess you'd have to adapt your code to deal with other archivers in the
future anyway.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 47421] tar task does not flush the buffer
correctly for a short block
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47421
--- Comment #3 from Kirk Turner <ga...@gmail.com> 2009-06-29 22:26:57 PST ---
I hadn't noted the part about the block requirements when reading up about tar
(I haven't been able to finding an actual format specification). But your
implementation does move the generated tar file to be inline with the GNU Tar
standard:
"When writing an archive, the last record of blocks should be written at the
full size, with blocks after the zero block containing all zeros. When reading
an archive, a reasonable system should properly handle an archive whose last
record is shorter than the rest, or which contains garbage records after a zero
block."
>From http://www.gnu.org/software/automake/manual/tar/Standard.html
But I can confirm that this has fixed the garbage issue. It hasn't broken any
tar implementations that I've used either - this is just from a manual
inspection using a binary editor.
It doesn't particularly help with what I'm doing - but that means I need to
handle these cases rather than assuming (incorrectly) that end of the tar was 2
512 bytes of nulls (the files currently will always be generated by ant - hence
the bug report here). I'm doing some on-the-fly appending to the end of the tar
where I don't know the beginning point to do block reads (e.g. self-extracting
code where the tar file is appended to the end of the executable binary)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
DO NOT REPLY [Bug 47421] tar task does not flush the buffer
correctly for a short block
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47421
Kirk Turner <ga...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Depends on| |40195
--- Comment #1 from Kirk Turner <ga...@gmail.com> 2009-06-24 20:41:55 PST ---
Added 40195 as a dependency - this is basically the same bug (that has been
marked as WORKSFORME)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.