🚀 go-pugleaf

Saving a file is one of the more elaborate parts of MacApp.  We spent 
several days figuring out the proper flow of control so that things 
happened properly.  The basic idea is the same as has been mentioned 
already (save a temporary file, delete the old version, and rename the new 
one when the save completes).  I will simply add a few other points.

(1) If you are doing a Save As or Save a Copy in, we delete the 
destination file immediately (if it exists).  This is because the user has 
already confirmed overwriting the file.  This maximizes the free disk 
space.

(2) We have the programmer tell MacApp the amount of disk space the 
document will require, and compare this against the amount of free disk 
space.  If there is enough to make a second copy we do so.  If there would 
be enough space if we deleted the old file, we put up an alert and ask the 
user if it is OK to do so.  (This is the default behavior; the programmer 
can tell MacApp to always overwrite the file or never overwrite the file.) 
 If ther ewouldn't be enough space even if the old file is deleted, then 
we signal an insufficient disk space error.

The last point is important.  You shouldn't blindly delete the original 
file if there is no chance of saving the new version (since then the file 
isn't saved anywhere).  Also, I think asking the user if it is OK to 
delete the original file is a good idea.  It lets the user know what's 
going on, and give them a feeling of being in control.  Also, if s/he is 
paranoid, they havean opportunity to save to a different disk.

The biggest problem here is estimating the required disk space.  In some 
cases, it isn't easy to do so without actually saving the file.

(3) In article <3665@ucdavis.ucdavis.edu> lim@iris.ucdavis.edu (Lloyd Lim) 
writes:
> 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

This IS very annoying.  In MacApp we simply copy all the finder 
information from the old file to the new one.  We don't try to interpret 
the bytes, so this should continue to work on future systems.  (The only 
problem is if the Finder adds more information that wouldn't be copied; 
then you aren't any worse off than now.)  

MacApp gets the file info from the original file and sets the info for the 
new file just after the file is created.  This copies the modification 
date, but that gets updated when the file is written out.  This preserves 
the file's position and color.

I don't know why MacDTS didn't suggest this.  Some people from MacDTS were 
involved with a recent MacApp code review, so if there is somthing wrong 
with this technique, they should have pointed it out.

(4) If the machine has HFS, then we use the HFS versions of Open, etc.  We 
also make sure that the dirID field of the param block is filled in with 
the correct non-zero value.  This prevents the Poor Man's Search Path from 
being used, and eliminates the chance of deleting a file in the System 
Folder by mistake.

(5) MacApp saves the file's modification date when the document is opened, 
and checks this agains the file when saving.  If the two are different, 
then someone else has saved over the file and we warn the user.  You can 
avoid this problem by keeping the  disk file open all the time.  
(This may actually be the preferable solution.)

Let me know if you have questions.


Larry Rosenstein, Apple Computer, Inc.

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1