Broken Squeak Map downloads?

When I try to download certain SqueakMap packages, including VMMaker, AioPlugin, and
XDisplayControlPlugin, I am getting errors. Others work fine, including OSProcessPlugin.
Did something break and/or change recently to cause this?

Thanks,
Dave

Transcript output looks like this:

Download from original url (http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/files/VMMaker-3.8b6.mcz) failed with this exception: empty stream
Trying server cache instead.
data was slow
data was slow
Download from server cache of VMMaker 12-3.8b6 failed with this exception: Incorrect SHA checksum of file from server


Download from original url (http://minnow.cc.gatech.edu/squeak/uploads/3350/XDisplayControlPluginV2-0.sar) failed with this exception: Incorrect SHA checksum of file from orginal URL
Trying server cache instead.
Download from server cache of XDisplayControlPlugin 2-2.0 failed with this exception: Incorrect SHA checksum of file from server


Download from original url (http://minnow.cc.gatech.edu/squeak/uploads/3384/AioPluginV1-1.sar) failed with this exception: Incorrect SHA checksum of file from orginal URL
Trying server cache instead.
Download from server cache of AioPlugin 2-2.0 failed with this exception: Incorrect SHA checksum of file from server

Hi!

"David T. Lewis" <[hidden email]> wrote:
> When I try to download certain SqueakMap packages, including VMMaker, AioPlugin, and
> XDisplayControlPlugin, I am getting errors. Others work fine, including OSProcessPlugin.
> Did something break and/or change recently to cause this?
>
> Thanks,
> Dave

I will take a look later tonight. I think I know why the server cache
isn't working - it is because asString36 is broken in 3.8+ - it
needlessly (nowadays) chops off the first 4 characters of the string. I
think this is one of the issues at least.

But... having the SHA sums fail on the original URL is... well, not
sure. Have you modified the files "in place" after registering the
releases on SM? You can force SM to recalculate the SHA sum by changing
the file name of the URL. So if you change it to "whatever" and then
back to the original it should be re-downloaded into the server cache
and re-calculated. I should add a button somewhere to do this manually.
:)

But the above bug with asString36 probably still makes the fallback on
the server cache to fail - but then at least the SMLoader will not
reject the original file from the original URL.

regards, Göran

On Tue, Apr 18, 2006 at 08:44:05AM +0200, [hidden email] wrote:
Thanks!

> But... having the SHA sums fail on the original URL is... well, not
> sure. Have you modified the files "in place" after registering the
> releases on SM? You can force SM to recalculate the SHA sum by changing
> the file name of the URL. So if you change it to "whatever" and then
> back to the original it should be re-downloaded into the server cache
> and re-calculated. I should add a button somewhere to do this manually.
> :)

I don't know about VMMaker, but the other two packages I mentioned are
files on a Swiki. I have not changed them, but the Swiki occasionally
gets repaired following vandalism attacks, so they might have been
reloaded from backups without me knowing it, or some such thing.

BTW, I did not know about this until somebody mentioned it to me, so
there could easily be other packages with broken SqueakMap links that
the maintainers do not know about. I suspect that VMMaker is one of
them, but there may be others.

Dave

Hi again!

"David T. Lewis" <[hidden email]> wrote:
Ehrm, seems to be more "file stuff" that is broken now due to the new
binary-not-being-default thing - so I really need to go over the code
once more, sigh.

I do want to alert you to one problem though: you are using the same URL
for both releases!

This means that the old 1.1 release is now... not available. It also
screws up the caching etc. The idea is that the file registered as the
download URL for a release should be immutable. If it is, then the
server can cache it, and so can the clients.

regards, Göran

I seem to be unable to get a file to upload properly; I try to send  
the new VMMaker and either it
a) simply stalls forever
b) uploads a 816kb file as a 1222kb file and then downloads that as a  
zip and fails to decompress.

So for now the newest VMMaker simply isn't there.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If you must choose between two evils, pick the one you've never tried  
before.

Hi Tim!

tim Rowledge <[hidden email]> wrote:
> I seem to be unable to get a file to upload properly; I try to send  
> the new VMMaker and either it
> a) simply stalls forever
> b) uploads a 816kb file as a 1222kb file and then downloads that as a  
> zip and fails to decompress.

Yes, both uploads and downloads were broken. Funny I didn't see these
things earlier - obviously my eyes were tired.
It is yet more of the
"must-send-binary-to-filestreams-these-days-to-make-them-behave"-issue.

regards, Göran

On Tue, Apr 18, 2006 at 12:28:17PM +0200, [hidden email] wrote:
>
> I do want to alert you to one problem though: you are using the same URL
> for both releases!
>
> This means that the old 1.1 release is now... not available. It also
> screws up the caching etc. The idea is that the file registered as the
> download URL for a release should be immutable. If it is, then the
> server can cache it, and so can the clients.

Oop, thanks. I had better fix that.

Dave

Hi Tim!

tim Rowledge <[hidden email]> wrote:
> I seem to be unable to get a file to upload properly; I try to send  
> the new VMMaker and either it
> a) simply stalls forever
> b) uploads a 816kb file as a 1222kb file and then downloads that as a  
> zip and fails to decompress.
>
> So for now the newest VMMaker simply isn't there.

Now I think it is fine. I renamed the file you had uploaded to the
"proper" name that you intended and given my last bugfixes it now seems
to download fine in a 3.8 image at least.

TIme to sleep.

regards, Göran