[comp.sys.mac.programmer] What's the "best" way to save a file?

rang@cpsin3.cps.msu.edu (Anton Rang) (02/14/89)

While watching all the discussion on the great Microsoft Word Save As
fiasco, I started thinking about the best way to do a "Save As" (or a
"Save", for that matter).  It seems to me that the following is the
safest way to do it, if the file is going to be saved "on top of" an
existing file.

	1. If doing "Save As", ask the user for the filename.
	2. Write out the new file, with some temporary name.
	3. Rename the "old file," if it exists, to a temporary name.
	4. Rename the new file to the old file's name.
	5. Delete the old file.

  The "old file" is the existing file; the "new file" is the one just
being saved.  The advantage of doing this is that the old file isn't
removed until the new file has been successfully written.  The
disadvantage is that you can't use "Save As" to free up disk space by
saving on top of an existing file.
  What do people think of this idea?  What are the biggest problems
you see with it?

+---------------------------+------------------------+----------------------+
| Anton Rang (grad student) | Things could be worse. | "Do worry...be SAD!" |
| Michigan State University | rang@cpswh.cps.msu.edu |                      |
+---------------------------+------------------------+----------------------+

lim@iris.ucdavis.edu (Lloyd Lim) (02/14/89)

In article <1811@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>While watching all the discussion on the great Microsoft Word Save As
>fiasco, I started thinking about the best way to do a "Save As" (or a
>"Save", for that matter).  It seems to me that the following is the
>safest way to do it, if the file is going to be saved "on top of" an
>existing file.
>
>	1. If doing "Save As", ask the user for the filename.
>	2. Write out the new file, with some temporary name.
>	3. Rename the "old file," if it exists, to a temporary name.
>	4. Rename the new file to the old file's name.
>	5. Delete the old file.
>
>  The "old file" is the existing file; the "new file" is the one just
>being saved.  The advantage of doing this is that the old file isn't
>removed until the new file has been successfully written.  The
>disadvantage is that you can't use "Save As" to free up disk space by
>saving on top of an existing file.
>  What do people think of this idea?  What are the biggest problems
>you see with it?

I just finished working on a major Mac product recently.  The scheme you
describe is almost exactly the scheme we used.  The only other addition is
that if there isn't enough disk space to save the temporary copy, the old
file is deleted first.  Thus, there really aren't any disk space problems
when space is tight although saving is not quite as safe.

What is the biggest problem?  A big one from the user's point of view.  When
you do a save in this manner, the new file gets a new icon position which
is different from the original file's icon.  I forget the details but for
some reason the usual File Manager calls for setting the Finder info don't
work correctly.  Anyways, every time you save a file, it's icon moves.

This is the worst when your file icon is on the desktop and you're using
MultiFinder.  When you save the file, it's icon disappears (!) because the new
file's icon is displayed inside the folder that the original file belonged to.
This is very disconcerting to the user that doesn't know what is happening.
A problem, of course, but we felt it was more important to have safer file
saving.

Mac DTS couldn't provide us with any solutions that would not break under the
next System/Finder release.  BTW, there is a solution that does solve this
problem but it doubles the file saving time (which is very unacceptable in
most cases).  You can save the new contents right on top of the original file
after saving a copy as described above or making a duplicate of the original.
To repeat, this method is sloooow.

+++

Lloyd Lim     Internet: lim@iris.ucdavis.edu
              Compuserve: 72647,660

tim@hoptoad.uucp (Tim Maroney) (02/14/89)

In article <1811@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>	1. If doing "Save As", ask the user for the filename.
>	2. Write out the new file, with some temporary name.
>	3. Rename the "old file," if it exists, to a temporary name.
>	4. Rename the new file to the old file's name.
>	5. Delete the old file.
>
>  The "old file" is the existing file; the "new file" is the one just
>being saved.  The advantage of doing this is that the old file isn't
>removed until the new file has been successfully written.  The
>disadvantage is that you can't use "Save As" to free up disk space by
>saving on top of an existing file.
>  What do people think of this idea?  What are the biggest problems
>you see with it?

It's a great appraoch, the one emacs uses.  There's only one big
problem -- you have to have enough disk space for both copies of the
file.  This is quite likely not to be the case on floppies.  You
should build in a check so that, if there isn't enough disk space for
both copies, you just overwrite the existing file in the "naive" way.
Don't notify the user, as it would only be confusing.

By the way, Save As must be able to save over an existing file.  I
don't see why that wouldn't work in this approach, though.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"The Diabolonian position is new to the London playgoer of today, but not to
 lovers of serious literature.  From Prometheus to the Wagnerian Siegfried,
 some enemy of the gods, unterrified champion of those oppressed by them, has
 always towered among the heroes of the loftiest poetry."
    - Shaw, "On Diabolonian Ethics"

David_Greg_Herlihy@cup.portal.com (02/15/89)

I believe the process you have outlined is more or less what Word
does when you Save a file ordinarily. It creates a temp file to 
save it to, deletes the old file, and renames the temp file to 
the document name. The advantage being if the power should fail, you
would at least have the pre-saved version.
You can verify this by saving an open document on a diskette with
less memory than the size of the file. Word will refuse.
The only danger seems to be the "Fast Save" option, which doesn't
safeguard the file as well.
Greg Herlihy

kent@lloyd.camex.uucp (Kent Borg) (02/15/89)

In article <1811@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes:
>While watching all the discussion on the great Microsoft Word Save As
>fiasco, I started thinking about the best way to do a "Save As" (or a
>"Save", for that matter).  It seems to me that the following is the
>safest way to do it, if the file is going to be saved "on top of" an
>existing file.
>
>	1. If doing "Save As", ask the user for the filename.
>	2. Write out the new file, with some temporary name.
>	3. Rename the "old file," if it exists, to a temporary name.
>	4. Rename the new file to the old file's name.
>	5. Delete the old file.

I see two problems here:

You will only be able to work with files that are less than half the
size of your free disk space.  Certainly if there is enough space for
the double save, fine on this count, but what if there isn't?  Not
everybody has lots of empty disk space.

Also, this scheme will not allow other applications to mess with your
resource fork, everything over there will get blatted unless you copy
it across from the old file.  Why, you ask, should any other
application be messing with other documents' resource forks??  Well,
Projector, Apple's source code/documentation/whatever management
system which is part of the new (beta) version of MPW does.  It leaves
info in a resource that tells it what revision the file is, where it
came from, who checked it out, etc.  Should Apple be doing this?  Why
not?

Your scheme also will not work if you are messing with some other
application's document.  Say you understand TEXT documents, that
doesn't mean you know about all the resources that might accompany a
document produced by unknown creator (window and scroll position, font
choice and size, etc.)

Seems you must adjust your scheme to preserve any resources that were
in the original file.

Kent Borg
kent@lloyd.uucp
or
hscfvax!lloyd!kent
or
kent%lloyd@hscfvax.harvard.edu