$ rpm -qf /usr/bin/pax pax-3.0-9 Found this while building 'gcc.4.1.1' from ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.1.1/gcc-core-4.1.1.tar.bz2 ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.1.1/gcc-g++-4.1.1.tar.bz2 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. bunzip2 gcc-core-4.1.1.tar.bz2 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] script The problem is in the g++ archive, not in the core archive. I included both for since that's what one does when building GCC. Here is a canned script that reproduces the problem along with the output.
Created attachment 135665 [details] script output
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.
Further info: 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.
pax-3.4-3.fc8