> > I note once more, with interest, that this problem seems to recur with
> > cloying frequency.
> >
> > Why don't we simply compress the changes file (and sources), and store the
> > compressed data in the IMAGE with code for decompression and deletion of
> > the image information when Squeak first starts up on that image?  Squeak
> > would then restore the files in the proper format always, and we don't need
> > to repeat the instructions about setting compression and decompression
> > parameters of applications.
>...
>
>These solutions don't solve the problem. I encountered it while ditching my
>PC and moving my Squeak files to my new Mac. The changes file was made bad
>by Stuffit, I figured out alright--eventually.

I respectfully disagree.  This finesses the problem entirely.  The 
problem derived from corruption of what the system thought was a text 
file, but the squeak system treats as a data file.  In almost every 
scenario where this issue was discussed, the corruption ocurred in 
the changes or source files, not in the original.  As conceived, this 
approach would obviate that problem entirely by transmitting those 
files embedded within the image, and then writing the information to 
disk in proper binary form.

In the proposal as understood, all you need to do is download an 
install image and a local VM.  When the local VM runs, it 
automagically installs the system, writing the "text" datafiles 
correctly in every case on every platform.  No longer would we need 
to rely on anyone having to "figure it out."

>But why not do as we always do otherwise, and let Squeak itself solve the
>problem. Ie. when opening a sources file, have it look for bad line break
>encodings, notify user, and offer to convert the changes file while
>preserving the original under another name.

Because its not a reversible conversion in every case.  And I don't 
believe the proposal set forth there is distinguished in that it lets 
"Squeak itself solve the problem."  That is also what I am proposing.