Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Try taking the same chunk of data and compressing it on both boxes. What happens? Also run file on each of your existing ones. Are the OSes the Same on both boxes? One of those gzips is misbehaving. Lastly, try ldd /path/to/gzip |grep found on the gzip executables.
Compression on both the boxes works perfectly. The files are readable.
Box 1 is an RHEL5, Box 2 is FC 14.
The output of ldd is here
Box 1 (gzip-1.3.5)
linux-vdso.so.1 => (0x00007fff265fc000)
libc.so.6 => /lib64/libc.so.6 (0x00000032b4000000)
There are times according to the man page (which I confess to having skimmed) that gzip does not decompress.
file: compressed with xx bits, can only handle yy bits
File was compressed (using LZW) by a program that could deal with more bits than the decompress code on this machine. Recompress the file with gzip, which compresses better and uses less memory.
-- has xx other links: unchanged
The input file has links; it is left unchanged. See ln(1) for more information. Use the -f flag to force compression of multiply-linked files.
I would try a run with -l, -t, & -f (3 runs in total) on the offending box. Also see if you can trap the error value