Slashdot Mirror
Open File Locking and Mac OS X?
ArcticMyst asks: "In Mac OS X the responsibility of locking open files has moved from the operating system to individual applications. With the exception of Apple's most recent release of AppleWorks, I have not been able to find many applications written for Mac OS X that will lock a network resident file when it is opened. Not marking a file as locked allows more than one user to have a file open, then edit and save back to the original file. Even most of Apple's own applications fail to do this. Apple does provide information on how to make sure that open files are not edited while they are open. Why do so many applications fail to provide this security?"
This doesn't actually lock the file for exclusive access, it just sets a status. Anyone who checks the status will see that it is locked for exclusive access, but will not be 'locked' out from accessing it. I think it's in the flock man pages. Is this correct?
Um, have you ever had anyone edit a Korn shell script underneath you? I would guess not.
This has the potential to be a good thing.
The other week I was doing disease modeling: I had written a Python program that would model the disease (using the 4th order Runge Kutta to numerically approximate the SIR model, if anyone cares) and then outputting it via the command line to a text file. I then had BBEdit open to look at the data and so I could bring it into pro Fit if the results looked interesting.
BBEdit is coded in such a way that it would automatically detect the change and update the text for me, making my life easier and preventing me from writing another script.
Not to say that this is universally good or that the above approach doesn't have flaws, but only that you *can* take advantage of something like this on a lot of levels--especially in a Un*x OS.
Integrate Keynote and LaTeX
It's a nightmare. With multiple incompatible schemes and hideous obscure function calls it's no surprise people can't/don't remember how to do it. Once upon a time I thought it was useful knowledge knowing the various arguments to calls like ioctl and fcntl. Those days have passed. I'd like to apply my few remaining functional neurons to actually solving the real problem in hand and let the OS do the tedious stuff. Reading that documentation from Apple took me back two or three decades!
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
The fact that multiple apps *can* have a file open for write access isn't necessarily a bad thing. If, say, you want to combine multiple output streams from programs, you can toss 'em all into one file (even opening a file immediately before actually writing to it and then closing it on an OS with forced-write-lock behavior cannot allow this). There are some things the "forcibly write locked" and some things the "multiple apps can write to a file" model are each good for.
For example, you're claiming that apps should establish locks on network-resident files. That's fine and dandy, until some app goes to the great computer in the sky with a file locked.
On UNIX, traditionally users are savvy enough to wipe out lock files. In the case of netscape navigator, the app simply handed the user a command to run to remove the lock. Hence, write-locking files (especially remote ones) can cause nastiness for users as well.
Finally, I hate to say it, but if you're trying to set up a collaboration system (as it sounds like you are), some sort of dedicated checkout system is probably better. For text files on UNIX, this usually means cvs, but other platforms have their own favored revision control/collaboration systems.
In general, I dislike *intensely* the emphasis that many desktop operating systems place on forcible locking. Windows is by far the worst culprit -- write-opened files cannot be opened for write, cannot be moved, and cannot even be renamed. Classic MacOS is a bit better -- you can move around write-opened files -- but I really think that UNIX's approach is pretty good. You have the ability to use *both* types of locking, and the default is the one that lets the user do the most -- so dead apps don't tie up files.
May we never see th
People seem to be interpreting this to mean that Mac OS X applications will never use file locking unless the programmer explicitly requests it. This may have been true prior to 10.2 (Jaguar), but is no longer the case. The tech note is a little bit sketchy on this point, but it was written before the release of Jaguar.
Applications that open files with calls to the standard Mac frameworks will use locking. A Carbon app that locks in OS 9 will still lock when running under a recent version of OS X.
Until this [major] oversight was fixed, workarounds were required in application code. This is no longer the case.
Only applications that use open() directly need to take extra steps to lock files. This is the way it's done in the Unix world, and Apple has chosen the correct implementation by not forcing the standard open() call to lock.
Mark