Hi!

On 05/13/2010 08:34 PM, Chris Muller wrote:
> Web-sites come and go...  This is why I think SqueakMap should keep a
> copy of the files in its own files area; they are generally small so
> space shouldn't be an issue.

Just so you all know - SM does have two features that might be good to 
know about:

1. You *can* upload and host files on SM if you like to. Some packages 
do. But you probably knew that.

2. SM *caches* the file pointed to by the release URL! This is not so 
well known, but when you enter a release (or edit the URL IIRC) SM will 
donwload that file, compute the SHA hash for it, and keep it on the server.

Now, when you download a file from the map the loader will compute the 
SHA hash and compare it to the one computed originally - and if it does 
*not* match - the loader will try to load from the SM server cache 
instead, for example:


	http://map.squeak.org/package/1e5499c3-129e-4e56-a338-0a2c113bb2c4/autoversion/3/cache

which will give you the SM server copy of:

	http://www.squeaksource.com/Aida/Aida-5.6.mcz

Now... there is one problem, if the file pointed to by the URL is 
changed "in place" then the SHA hash will fail and the cached version 
will be used instead.

So, one way to "screw it up" is to register a release with a URL that 
fails - say returns a 404. SM will then consider that result to be the 
correct result and compute an SHA hash and store the 404.html file as 
the cached "proper file". When the real file is placed on that URL it 
will not work since the SHA hash will be different and SM will instead 
rely on the cached file (which of course is a silly 404.html).

You can see if a download ends up using the cache by looking at transcript.

A bunch of years ago I published a doit that iterated over the map and 
downloaded all releases, you can easily write such a script and also 
find out which ones fail SHA checks etc. I think I did it for the Squeak 
CD which was mentioned.

regards, Göran