Red Hat Bugzilla – Bug 205324
'pax' truncates long file names when extracting an archive
Last modified: 2007-11-30 17:11:42 EST
$ rpm -qf /usr/bin/pax
Found this while building 'gcc.4.1.1' from
Problem doesn't show up till the 'make install' phase.
Had to switch to using 'tar'. Simply expanding
the above with 'tar' and 'pax' and then comparing the names
with 'find' and 'diff' should demonstrate the differences.
Sorry, I can't reproduce it.
pax -r -f gcc-core-4.1.1.tar
and I got some result with
tar -xvf gcc-core-4.1.1.tar
Created attachment 135664 [details]
The problem is in the g++ archive, not in the core archive.
I included both for since that's what one does when building
Here is a canned script that reproduces the problem along
with the output.
Created attachment 135665 [details]
Created attachment 135666 [details]
differences file created by script
And now that I look, I see the magic number is 100 characters.
Any longer pathnames get chopped.
Apparently the 100 character limit is specified in the
POSIX standard for 'pax'. At a minimum, I see it as a bug
that 'pax' truncates to 100 characters silently, without
giving any warning. In addition, I don't see the "value add"
in slavishly conforming with the POSIX spec at the expense of
compatibility with 'tar'. What does one gain by chopping
the path names? Nothing but trouble.
It may be changed in fedora core, but unfortunately not in RHEL
Created attachment 159180 [details]
patch for long names
Filenames in that archive are saved using some sort of GNU hack (the archive is
non-standard ustar). They are read correctly by pax but additionaly truncated
to 100 characters and then written to disk. I thing this is total nonsense so
I'll apply it to rawhide soon.