Cees,

> On Tue, 2003-02-25 at 23:25, Andreas Raab wrote:
> > This can't be right - if we give the archive an absolute
> > path to extract something to, why would it forcefully 
> interpret this as a
> > relative one and even skip the drive?!
> > 
> I think it is a Good Think and I hope it was a modification done on
> purpose. If you disagree, I'll be happy to put a SAR up on SM 
> with files like 'C:\WINDOWS\..whatever kills your system...'

This argument seems bogus to me. For one thing, it can be equally
problematic to put something relative to the image directory - who says
there's nothing in there?! For another one, just because you _can_ do bad
things doesn't mean there is no good use for absolute paths. In the concrete
case, for example, the Win32Fonts installer attempts to put the font plugin
into the VM directory - a perfectly legal behavior in my opinion. Thirdly,
"just" having ZipArchive behave this way, doesn't solve any problem
whatsoever unless you prevent people from changing/deleting files generally.
If you (or your OS) do so, then there's no reason for the ZipArchive to
behave that way.

> The ZIP is broken for having absolute paths, IMNSHO.

The ZIP itself doesn't have any absolute paths. The installer script asks
the archive to extract the font plugin to the place where the VM lives (due
to Smalltalk>>vmPath that's an absolute location).

Please keep in mind that my major argument here is that if we request to
extract a file to some clearly specified absolute location then ZipArchive
should adhere to this request. If it doesn't it will only confuse people -
yes, they can work around this (simply open the file yourself and copy the
stuff into it) but that seems pretty awkward to me.

Cheers,
  - Andreas