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"
lsr@Apple.com (Larry Rosenstein) (02/15/89)
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
lim@iris.ucdavis.edu (Lloyd Lim) (02/15/89)
In article <674@internal.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >[...] > >(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 > >[...] > >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. We did exactly this and the problem still occurred. My memory is fuzzy but I think it occurred when you use MultiFinder and you create a document, save it, make modifications, and save again in the same session. You can see the icon bouncing around in the Finder. It has to do with the Finder info not being set yet. I think it also happens with files on the desktop even if they were saved before you started up your application. Try it with your MacApp-built applications. We don't interpret the Finder info either so I don't know what you're doing differently. +++ Lloyd Lim Internet: lim@iris.ucdavis.edu Compuserve: 72647,660 US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
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
lsr@Apple.com (Larry Rosenstein) (02/16/89)
In article <3670@ucdavis.ucdavis.edu> lim@iris.ucdavis.edu (Lloyd Lim) writes: > I think it occurred when you use MultiFinder and you create a document, >save it, make modifications, and save again in the same session. You can see >the icon bouncing around in the Finder. It has to do with the Finder info >not being set yet. I think it also happens with files on the desktop even if > they were saved before you started up your application. Try it with your > MacApp-built applications. We don't interpret the Finder info either so I tried the MacApp DrawShapes sample that comes with MacApp. I created a document, colored it blue and moved it to the desktop. Then I opened it, made a change, and saved it. The file stayed where it was and remained blue. This was under MultiFinder. There might be some subtle point that I just don't recall off hand (it's been a while since I wrote the saving code). MacApp has used basically the same saving code since its first release. Larry Rosenstein, Apple Computer, Inc. Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
alexis@ccnysci.UUCP (Alexis Rosen) (02/21/89)
Larry Rosenstein wrote a nice article on MacApp's "Save As..." behavior. I am distressed by one thing- he makes no mention of copying over foreign resources! Does this mean that every time MacApp saves, it will blow away all of my resources? For example, if I've loaded a WP document with a bunch of laser screen fonts because I like the Adobe ones better and I sometimes edit this document on a machine with Apple fonts, will these fonts (and FONDs and NFNTs) get destroyed? Alexis Rosen alexis@ccnysci.uucp
lsr@Apple.COM (Larry Rosenstein) (02/22/89)
In article <1302@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: > >Larry Rosenstein wrote a nice article on MacApp's "Save As..." behavior. >I am distressed by one thing- he makes no mention of copying over foreign >resources! Does this mean that every time MacApp saves, it will blow away The only reading & writing that MacApp does is for the Print Info record, which is put into the data fork. Even doing this is done only if the programmer specifically requests it. So it is up to the programmers to copy over all the resources in the document. This is an area that MacApp should handle automatically (if the programmer uses the resource fork). MacApp's support for saving in the resource fork is not as good as it could be. I mentioned this to one of the MacApp people, and he said that there are various ideas floating around for improving the document saving code (post-MacApp 2.0. Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
alexis@ccnysci.UUCP (Alexis Rosen) (02/24/89)
Auto-copying the resources if the program uses resources is good, but not quite good enough (IMHO). Unless the programmer specifically says otherwise, any existing resources should get moved over. Why? Because at this point, it has become a legitimate technique to store your resources in a foreign file. Many programs use this technique. Just because you don't use resources in your documents doesn't mean that other programs don't use resources IN YOUR DOCUMENTS. Alexis Rosen alexis@ccnysci.uucp