Issue 6054 in pharo: Error when reading zip files with Squeak date/time format

Status: Accepted
Owner: [hidden email]
Labels: Type-Bug Milestone-2.0

New issue 6054 by [hidden email]: Error when reading zip files with  
Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

Pharo 2.0

Pharo and Squeak have interpreted DOS timestamps incorrectly. It is now  
fixed in Pharo [1], but trying to correctly parse (per the DOS format) an  
incorrect (pre-fix) timestamp can cause errors.

[1] Issue 5873: [BUG]: ZipArchive does not correctly zip hierarchies


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixReviewNeeded

Comment #1 on issue 6054 by [hidden email]: Error when reading zip  
files with Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

Attached are two cs files that have a temporary fix enabling us to load mcz  
and other zip files, even if they have the old, incorrect date format. They  
should be refactored and there is a larger question to discuss [1], but  
they work under manual testing.

The new behavior when reading zip file timestamps is:
* parse as a DOS timestamp
* if an error is encountered, fall back and treat it like a Squeak (i.e.  
incorrect) DOS timestamp. This may return an incorrect result, but will not  
cause an error

The changes were tested by hand on Balloon-CamilloBruni.85.mcz, which Steph  
was having a problem with because there was 13 as a month index, which blew  
up [1]

[1]  
http://forum.world.st/zip-bug-IMPORTANT-probably-related-to-the-recent-Zip-changes-td4634224.html

Attachments:
        ZipFileMember-readCentralDirectoryFileHeaderFrom.st  1.7 KB
        ZipFileMember-readLocalDirectoryFileHeaderFrom.st  1.7 KB


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixToInclude

Comment #2 on issue 6054 by [hidden email]: Error when reading zip  
files with Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

Works for me.

Please integrate as soon as possible.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: OnHold

Comment #3 on issue 6054 by [hidden email]: Error when reading zip  
files with Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

Give me an hour. I'm working on a slice that includes this, a test, and a  
bug fix with some FS cleanup...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: FixReviewNeeded
        Labels: Importance-High

Comment #4 on issue 6054 by [hidden email]: Error when reading zip  
files with Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

Fix in inbox:  
SLICE-Issue-6054-Error-when-reading-zip-files-with-Squeak-datetime-format-SeanDeNigris.1
* When reading zip files, treat invalid, error-causing DOS timestamps as  
the old, incorrect format from Squeak
   - Fix ZipFileMember>>read*DirectoryFileHeader* methods
   - Add (now)-passing test for timestamp that caused the issue to be  
reported (see comment 1 in issue or test comment)
* Delegate DOS timestamp processing to DateAndTime
   - Remove date/time zip/unzip methods from ArchiveMember
   - Update Zip*Member reading/writing methods
   - Remove zip-related methods and protocols from Date, Time, and Integer
   - Remove associated tests
* When writing directories to zip files, append trailing slash to name,  
which is required (at least Mac OS X can't handle without)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 6054 by [hidden email]: Error when reading zip  
files with Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

Successfully loaded slice into 20140
* all compression tests pass
* The following fails before slice, passes after "ZipArchive new  
readFrom: '/path/to/Balloon-CamilloBruni.85.mcz'"


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Integrated

Comment #6 on issue 6054 by [hidden email]: Error when reading zip  
files with Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

in 20141.
I reviewed the code and I love your comment in the slice!!!



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 6054 by [hidden email]: Error when reading zip  
files with Squeak date/time format
http://code.google.com/p/pharo/issues/detail?id=6054

N.B. This solves the main problem of not being able to load mcz files. If  
we determine more accuracy is needed interpreting timestamps for mcz files  
in particular (does not apply to zip files in general), we could do another  
check: that the files do not pre-date Monticello itself. The earliest date  
I could find is 17 November 2002 [1], so something like the following could  
be done:
        [ | monticelloReleeaseDate |
                lastModFileDateTime := DateAndTime fromDosTimestamp: dosModifiedTimestamp.
                monticelloReleeaseDate := '17 November 2002T00:00:00' asDateAndTime.
                (lastModFileDateTime < monticelloReleeaseDate or: [ lastModFileDateTime >  
DateAndTime now])
                        ifTrue: [ self error: 'impossible mcz timestamp'] ]
                on: Error
                do: [ DateAndTime fromSeconds: 2492992800 + dosModifiedTimestamp ].

Also, there seems to be a lot of duplication in how MC handles zip files.  
If you browse senders of #readFrom: and look in the MC-related classes,  
you'll see a handful of very similar looking zip reading snippets.  
Probably, the first step in applying the check above would be to funnel all  
these into a common entry point. Maybe e.g. a MczArchive class would make  
sense...

[1]  
http://map.squeak.org/package/66236497-7026-45f5-bcf6-ad00ba7a8a4e/autoversion/1


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker