Menu

#67 vfs::zip does not decompress

open
nobody
5
2009-02-26
2009-02-26
Anonymous
No

I am using Tcl 8.5.5, tclvfs-20080503 and memchan-2.2.1 freshly built from source code on Linux/x86-64.

Reading from a file in a Zip file returns the compressed data rather than the uncompressed data that I expected.

E.g., the attached zip file contains the file DESCRIPTION.txt from the tclvfs distribution:

intelbox:~/soft/pkg/tclvfs-20080503 > unzip -l -v test.zip
Archive: test.zip
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
490 Defl:N 298 39% 10-13-03 07:15 59cebccf DESCRIPTION.txt
-------- ------- --- -------
490 298 39% 1 file

Note how the original file size is 490 bytes and the compressed size is 298 bytes.

intelbox:~/soft/pkg/tclvfs-20080503 > tclsh8.5
% package require Memchan
2.2.1
% package require vfs
1.3
% package require vfs::zip
1.0.1
% set fd [vfs::zip::Mount "test.zip" /zip]
file5
% set f [open "/zip/DESCRIPTION.txt"]
mem0
% fconfigure $f -translation binary
% set data [read $f] ; puts "read [string length $data] bytes"
read 298 bytes

As you can see, I only get 298 bytes of data. Printing data to the console shows binary data, which I assume is the compressed data.

Obviously I expect to read the original text file using the above code fragment.

Discussion

  • Nobody/Anonymous

    test.zip

     
  • Nobody/Anonymous

    It turns out that this was caused by an improper setup. The Trf extension (which is apparently used to uncompress) was not available, and there was a conflict with the zip capabilities from tkImg.

    Inspection of the vfs::zip code shows that it returns the compressed data rather than an error if anything fails during uncompression.

    So the title of this bug should probably be changed to "vfs::zip should return appropriate error messages rather than failing quietly".

     

Log in to post a comment.