> I came across some odd behavior with a 0 length file in the repository and > I'm wondering if this is expected due to some change that was made during > the last few months. > > Back in July, we had a 0 length file in one of our packages. The hashval > that is calculated for the 0 length file is: > > da39a3ee5e6b4b0d3255bfef95601890afd80709 > > Back in July, the compressed file that was stored for this was 183 bytes. > > Now, the compressed file that is stored in the repository for this is 20 > bytes. > > If you run gzcat on either of these files, you get back the 0 length file. > However, with the chash value for the compressed file now being put into > the manifest and checked on downloads, if you have a package with a chash > based on one size, but the file in the repository is the other size, the > error is detected during the download and the install fails. > > BTW, we have a 0 length file in our software now: > > proto/root_i386/usr/lib/python2.4/vendor-packages/mako/ext/__init__.py > > Was there a change made to how files are compressed when they are > published? Or is the compression algorithm unstable for 0 length files?
We changed how the files are being compressed. (This was part of bug 1018) In order to verify the hash on the compressed content, files with identical content need to have the identical chash values. The previous incarnation of the gzip algorithm included filenames and access times. This meant that if we compressed a file with identical contents but a different name, we got different chash values. I changed our gzip library to omit any information that would be unique to a file. The chashes work correctly now. The behavior that you're seeing is intended. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
