[squeak-dev] Image damaged due to IO error while saving

David T. Lewis lewis at mail.msen.com
Fri Sep 3 22:48:37 UTC 2021

On Fri, Sep 03, 2021 at 06:24:32PM -0400, David T. Lewis wrote:

> On Fri, Sep 03, 2021 at 10:04:18PM +0000, Thiede, Christoph wrote:
> > Truncate? It has still a very usual file size ... But when I try to open it, the VM asks me for another image file, so apparently, it cannot read it. No idea what's going on here ...
> > 
> > 
> > Best,
> > 
> > Christoph
> > 
> > ________________________________
> > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von David T. Lewis <lewis at mail.msen.com>
> > Gesendet: Samstag, 4. September 2021 00:01:54
> > An: The general-purpose Squeak developers list
> > Betreff: Re: [squeak-dev] Image damaged due to IO error while saving
> > 
> > On Fri, Sep 03, 2021 at 09:02:07PM +0000, Thiede, Christoph wrote:
> > > Or is there maybe, just maybe some kind of automatic image repair tool? One that does not require in-depth knowledge of the file format internals of .image files? :-)
> > >
> > 
> > No, if you truncate the image file, it's junk.
> > 
> > Dave
> > 
> I don't know what the failure mode was on Windows (file system full?
> something else?). Regardless of the underlying failure, if you write
> the image file and the write does not successfully complete, then
> you almost certainly have a junk file that cannot be fixed.
> But to your other question, could we check for the failure and not
> exit the image, that's definitely worth looking into.
> Take a look at SmalltalkImage>>snapshotEmbeddedPrimitive and
> SmalltalkImage>>snapshotPrimitive. If the method comments are
> right, then a nil result would indicate a write faiure. I don't
> know if the actual primitives in the VM behave this way (if not
> they could be fixed). But if that is how the primitives behave,
> then it should be possible to add a check for nil to prevent
> exiting the image after a failed write.
> I do not see any such check in SmalltalkImage>>snapshot:andQuit:withExitCode:embedded:
> so it would be worth looking at this to see if a nil check could
> be added to protect against the kind of failure you saw.

Actually, I need to retract this. There actually *is* a nil check,
and it works as advertised for the case of a Unix VM trying to
save the image to a write protected file. So I think we would
need to understand the actual write failure that happened on Windows,
and see if the Windows VM is handling it in an appropriate way.


More information about the Squeak-dev mailing list