Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbvax!cory.Berkeley.EDU!korn From: korn@cory.Berkeley.EDU.UUCP Newsgroups: comp.sys.mac Subject: Re: How to write TEXT editors (part 1 of 2) Message-ID: <20860@ucbvax.BERKELEY.EDU> Date: Sat, 19-Sep-87 05:11:42 EDT Article-I.D.: ucbvax.20860 Posted: Sat Sep 19 05:11:42 1987 Date-Received: Sun, 20-Sep-87 14:23:34 EDT References: <3875@cisunx.UUCP> <20831@ucbvax.BERKELEY.EDU> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: korn@cory.Berkeley.EDU.UUCP (Peter "Arrgh" Korn) Distribution: world Organization: What, me organized??? Lines: 60 Keywords: System 4.1 and newer text edit Somewhere toward the end of a very good and informative posting, David Oster (oster@dewey.soe.berkeley.edu) wrote: > (m) Suppose the user opens a document in your program, then deletes the data > file in multi-finder, or renames it, or moves it to another folder. The Apple > user interface guidline people want me to open the file, and not close it > again until the user closes or quits. > I prefer to handle this problem by reading into memory the entire document, > including the finder info and the creation and modification times, and any > resources, then closing the file. Let the user do horrible things to the > copy on disk. When the user saves, if my code can't find the original file, > or if the modification date doesn't match, it puts up an sfPutFile dialog > with an explanatory dialog below it on the screen: > "Something changed this file since the last time it was saved. I suggest > you "Save As" this file with a different name." > > The advantage of this scheme is there is no limit to the number of open > documents you can work with (as opposed to the small number of simultaneously > open files) and the program doesn't have to worry about the user renaming > an open file, or changing its folder. > > (Thanks to David Dunham of Maitreya Designs for telling me this idea.) The idea is a neat one, but it turns out there is a situation in which it's very *dangerous* Imagine if you will a network. It has many machines on it, most of which are workstations, and some of which are servers. Imagine that two workstations are editing the same file on a server. One read in the file at 1:00pm, the other at 1:18pm. The first one finishes it's changes, and writes it back at 1:20pm. The other finishes at 1:31pm, and writes it's changes _on_top_of_the_first_set_. You immediately tell me "Peter, this can't happen, David's algorythm takes care of that." Well, in theory it does. But in practice, it can fail, because the two Macs in question (the workstations) may have a slightly different idea of what time it is... The mac that gets the file at 1:18pm may be 3 minutes fast, and think that it's really 1:21pm. When that mac goes to write the file back, it notices that the the last save to the file happened 'before' this mac got it, so it 'knows' that it's ok to save on top of it. and whomp-o, you've lost data. (and don't think this doesn't happen in networks; it happens all to often!) A slightly different scheme that works on the same principle might increment some number, an 'in use' number. Each time an application edited a copy of that file, it would increment the 'in use' number. Each time it closed the file, it would decrement that number. If it saw that the number was > 0 at save time, it would give the user the dialog, and let the user decide. This method also has it's problems. It's more complex, and it requires more writes to the file (even if I 'save as', I still have to decrement the 'in use' number). And the file might be replaced with one that has a lower (or higher) 'in use' number than it should have, wreaking havoc. Perhaps the safest way of dealing with it all is to just set the busy bit. That way nobody can mess with the file behind your back (without having to go through an override that requires they think about what they are doing). Peter -- Peter "Arrgh" Korn korn@ucbvax.Berkeley.EDU {decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!korn