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?"
The decision to allow multiple processes to write to a single file was made by Ritchie and Thompson in the early days of Unix's development at Bell Labs. OS X is a BSD, so it inherits this characteristic.
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Apple has quietly entered the groupware collaboration market.
-Pete
Soccer Goal Plans
From the provided link...
"Opening a file from classic Mac OS (pre Mac OS X) with fsWrPerm, fsRdWrPerm, or the default fsCurPerm, meant that any other application trying to open that same file with write access would not be able to do so. Usually an fsRdWrPerm error would be returned when other attempts were made to open the file for write access, though attempts to open such a file for read only access would succeed. This default behavior allows for one "writer" and multiple "readers" of the file. Mac OS X's BSD subsystem does not enforce file read/write privileges in the same way as classic Mac OS. Opening a file for writing does not ensure other processes can not write to the same file. The default behavior of BSD allows for multiple "writers" to a single file. In the current implementation, all of the File Manager calls in Mac OS X call through to the underlying BSD file system. As a result, opening a file via PBHOpenDF, PBHOpenRF, PBHOpen, PBOpenFork, FSOpenFork, HOpen, etc. on a local volume and passing in a permissions value of fsCurPerm, fsWrPerm, or fsRdWrPerm does not guarantee exclusive file access on Mac OS X."
Ergo, this is a significant and recent change of direction for Mac developers.
Also the average coder, in my experience, does not think about multi-user issues until problems roll in from the field. Finally, established test suites would not have been testing for this.
A point to bitch about sure, but to be expected if you read your submitted background link.
Bill
bamph
Blah! You call this an innovation?! Back in the days we had SHARE.EXE to handle file locking which is not present in Windows 3.x. Of course, sometimes files mysterically remained locked when nothing was running, but at least it's safe until next reboot. Most important, a user had full control over this locking mechanism by NOT loading SHARE.EXE during boot, then more than one user could access to the same file!
Talking about reinvent the wheel...kids these days...
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
what is the deal? Your favorite application does not provide file locking? File a bug for this. Most of those coders just do not think about multiuser environments.