Re: ::scr saving

[Chris Devers <cdevers@xxxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 20 Feb 2002, Andy Wardley wrote:

> One of many neat features was that there was no "load/save" just a 
> "disk" button.  You put a floppy in, hit the "disk" button and it
> loaded the contents into memory.  When you wanted to save your changes
> back to disk, you hit the "disk" button.  Easy for the machine to 
> work out that the memory has changed (so save back to disk) or the 
> disk has changed (load into memory).

Could it handle the situation where there are changes to both the disc and
the memory image? Load a file, eject the disc & put it in another machine,
edit in different ways on both machines, save on machine #2, move the disc
to machine #1, hit the "disc" button. What happens then?

You could resolve this by auto-saving before hitting eject, but that
implies that the disc has to be in the drive before working on the file. 
That does & doesn't make sense -- it's fine if you want to keep an
accurate copy of the file on the disc, but can you save to a new disc? 

It's an interesting suggestion, but it raises as many questions as it
seems to resolve. [Of course, that itself might be a sign that it's an
idea worth trying out...]
 
> The answer is that it's just a throwback to days when we didn't have
> cheap disks, or you had to rewind a tape when you wanted to save 
> something.

...know how the autosave feature on Microsoft Word works? Apparently it
does some kind of a diff & appends any detected changes onto the end of
the file, rather than making changes in place, because this ends up being
a bit more efficient in terms of disc accesses, and on slow hardware that
Word was written for this was a big deal. 

If you'd like to test this, make sure the autosave feature is on, then
type up a few paragraphs, allow it to save your work, then delete most of
it & replace with "hello world".  Open up the resulting .doc file in a
text or hex editor and you'll see everything you typed, including the
sections that you thought you had deleted. 

This helps explain why .doc files are almost always ridiculously bloated,
and why it's such a terrible format for distributing any kind of sensitive
information that needs to be purged in some way. Apparently there have
been cases where e.g. government/military/corporate documents have been
released in edited form as .doc files, and supposedly excised material was
still there for those that knew how to find it.
 



--
Chris Devers

"Okay, Gene... so, -1 x -1 should equal what?" "A South American!"    
[....] "no human can understand the Timecube" and Gene responded
 without missing a beat "Yeah.  I'm not human."