[BUG][3.4] Etoys broken due to ZipArchiveMember>>fileName

Ned Konz ned at bike-nomad.com
Tue Feb 25 23:20:57 UTC 2003

On Tuesday 25 February 2003 02:55 pm, Andreas Raab wrote:
> Hi Guys,
> I seem to have it with ZipArchive today. I was hunting a bug in the
> project publishing code in the Squeakland plugin and just happened
> to use a 3.4 image (I still had it open since I was playing with
> the Vera fonts - see the other message). It broke immediately which
> (at first) I happily thought was the problem I am looking for (the
> symptoms were "right").
> Unfortunately it wasn't. Turns out that ZipArchiveMember>>fileName
> was changed to return a platform-specific path which breaks the
> entire resource management machinery (both publishing and loading)
> relying on the fact that zip archives contain "canonical"
> unix-style path names (if any). In short, that makes eToys unusable
> in 3.4 since all "reasonably complex" sketches drawn with 3.4 will
> come out as scaled stubs only (e.g., they will look horribly washed
> out - see attached pictures).

Do you have CS 5161 loaded? That CS reverted that particular breakage.

fileName should return whatever's in the Zip.

>From the preamble to 5161:

My recent changes to fileName in ArchiveMember broke project loading 
in non-Unix systems.

This reverts fileName so that it returns the raw Zip name, and adds 
localFileName for use when you need a name that's compatible with the 
local file system.

Ned Konz

More information about the Squeak-dev mailing list