I believe I've found a bug in plzip. Apologies for rambling. software: Slackware 14.2 (32 bit) gcc (GCC) 5.3.0 plzip 1.6
hardware: Intel(R) Core(TM) i7 CPU 930 @ 2.80GHz quad core with hyperthreading 6GB RAM (not a typo) fileset: slackware-current sources. all '*.tar.*' decompressed to '*.tar' test: Compress each tarball with 'plzip -vf9 foo.tar' Tarballs 421969920 bytes & larger: fail to compress Tarballs 305926656 bytes & smaller: compress successfully Out of 1591 tarballs tested, 10 reported errors as: foo.tar: Not enough memory. Try a smaller dictionary size plzip: Deleting output file 'foo.tar.lz', if it exists. A single time the error was reported as: foo.tar: Not enough memory. Try a smaller dictionary size plzip: Deleting output file 'foo.tar.lz', if it exists. plzip: Write error: Bad file descriptor Successive attempts with 'plzip -vf9 -n8 foo.tar' through to 'plzip -vf9 -n3 foo.tar' eventually compressed the outliers. Tests were also performed on the following hardware using 'plzip -vf9 foo.tar' with no errors. Intel(R) Atom(TM) CPU N270 @ 1.60GHz single core with hyperthreading 1.5GB RAM Intel(R) Atom(TM) CPU D525 @ 1.80GHz dual core with hyperthreading 2GB RAM Intel(R) Celeron(R) 3205U @ 1.50GHz dual core without hyperthreading 8GB RAM Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz dual core with hyperthreading 8GB RAM Please note that while specifying '-n' & '-s' options are functional solutions, they are unacceptable for the intended use case. Regardless of a machine's hardware, the resulting compressed files must be identical/predictable. Erik -- Talent hits a target no one else can hit; Genius hits a target no one else can see. -- Arthur Schopenhauer _______________________________________________ Lzip-bug mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lzip-bug
