On May 31, 2011, at 3:06 PM, Cyril Lavier wrote: > On 05/31/2011 11:39 PM, John Clements wrote: >> On May 31, 2011, at 2:26 PM, Cyril Lavier wrote: >> >>> On 05/31/2011 10:21 PM, John Clements wrote: >>>> A search of the debian-backports mailing lists generates no hits for "pax", hope this isn't a known issue... >>>> >>>> The version of 'pax' associated with squeeze appears to be broken for all .tar files: >>>> >>>> clements@computer:/tmp$ cat> foo >>>> oseutheth >>>> clements@computer:/tmp$ tar cvf foo.tar foo >>>> foo >>>> clements@computer:/tmp$ pax -v< foo.tar >>>> -rw-r--r-- 1 clements clements 4294967306 May 31 13:16 foo >>>> pax: ustar vol 1, 1 files, 10240 bytes read, 13814518390877841716 bytes written. >>>> >>>> ... that is, it reports a size of (very large integer) for a tar file containing only one file of about 10 chars. This, in turn, means that the mail filter amavisd-new chokes on all .tar files that it receives. >>>> >>>> The updated version of pax (1:20090728-2) does not exhibit this behavior on my machine (debian squeeze, i686), and it appears to me that adding the updated version to either squeeze-backports or to squeeeze itself would be a good idea. >>>> >>>> Cheers! >>>> >>>> John Clements >>>> >>> Hi John. >>> >>> I also think backporting pax would be a good idea. >> Right, me too. >> >>> Maybe the issue is the same as reported on bug #317466 as apparently, your foo.tar weighs 4GB. >> Per the transcript above, the tar file contains only one file of ten characters. The tar file itself is 10K. Very small. It's true that pax *thinks* that the file is large. If that's what you're saying, then perhaps we agree. >> > Yes, this is why I think this bug and your issue may have the same source. > > Also, I just tried on a Squeeze AMD64 system, and here is the transcript : > > cyril@darwin:~$ echo "oseutheth" > foo > cyril@darwin:~$ tar cvf foo.tar foo > foo > cyril@darwin:~$ pax -v< foo > foo foo.tar > cyril@darwin:~$ pax -v< foo.tar > -rw-r--r-- 1 cyril cyril 10 Jun 1 00:02 foo > pax: ustar vol 1, 1 files, 10240 bytes read, 0 bytes written. > > Apparently, there is no problem under amd64. > > So I think the fact that pax considers the "foo" file as 4GB makes him crash. > > I think you can report a bug for this issue (and you can include my transcript in it) to make this backport add more relevant, because of this bug. To make sure I understand you: in debian, it's considered appropriate to file bug reports against earlier versions even when the reported bug is resolved by a later version? If that's correct, then I'll cheerfully submit the bug. Many thanks, John Clements
Attachment:
smime.p7s
Description: S/MIME cryptographic signature