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?"

Comments

Common to all Unixes

[dramage]

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.

Too easy...

[mildness]

"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?"

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

Re:Depending on how you code...

[c13v3rm0nk3y]

Type man tail next time you get a chance

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.