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.
...and while classic MacOS locked a file when you opened it with FSpOpenDF(), the Unix-based OS X doesn't automatically handle it. So, I'd guess the answer to the original question is that Unix-background developers don't lock OS X files because they don't lock files and Mac developers don't because they never had to worry about it before.
What I'm listening to now on Pandora...
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?
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...
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
No, tail is for looking at the n last lines of a file, or to follow a file that has data being added to the end of it.
If you regenerate the entire file, or write to it via random access, the output from tail will be less than helpful. It will be of even less help if the writing process creates a brand-new inode (or whatever) on the underlying filesystem. Good text editors know you care about the filename, and not the actual file as it resides on the filesystem, and behave properly.
As a rule, however, most text editors will let you read any file that is open for write elsewhere. Well, the good ones do, anyway. I actually like when gvim reports "the file has changed, do you want to refresh it" as I know something has happened to the output I need to look at.
-- clvrmnky