Slashdot Mirror

← Back to Stories (view on slashdot.org)

Open File Locking and Mac OS X?

Posted by Cliff on from the stepping-on-some-other-processes-files dept.

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

8 of 33 comments (clear)

  1. Common to all Unixes by dramage · · Score: 5, Informative

    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.

  2. Lock the file before you open for write! by Draoi · · Score: 4, Informative
    Surely, it's only good practise when opening a file for write, that you use O_EXLOCK in the flags.
    fd = open( "foo", O_RDWR | O_CREAT | O_EXLOCK);
    Everyone else does this ... right??
    --
    Alison

    "It is a miracle that curiosity survives formal education." - Albert Einstein

    1. Re:Lock the file before you open for write! by DiSKiLLeR · · Score: 4, Informative

      Apparently not...

      Most people don't use the open() system call anyway. They use fopen(), or they use fstream in C++, or they do it in Carbon or Cocoa in MacOS X....

      So no, i guess they do not lock their files...

      D.

      --
      You can tell how powerful someone is by the magnitude of the crime they can commit and be able to get away with.
    2. Re:Lock the file before you open for write! by CoolVibe · · Score: 2, Informative

      Yes.

  3. Too easy... by mildness · · Score: 5, Informative
    "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

    --
    bamph
  4. Re:..file a bug report? by Twirlip+of+the+Mists · · Score: 4, Informative

    The term you're evidently groping for is RFE: request for enhancement.

    It's even got the same number of letters as "bug." Handy, no?

    --

    I write in my journal
  5. Re:Depending on how you code... by c13v3rm0nk3y · · Score: 5, Informative
    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.

    --
    -- clvrmnky
  6. Re:The sky is falling! by arcticmyst · · Score: 2, Informative

    I discovered this little feature using OS X 10.2.3. I have retested under 10.2.4 and it is still an issue. Give it a try. Try it with the file resident on Sun, MS, or Mac OS servers. While setting the share point to honor standard Unix file permissions _may_ give you a message that the file is open when you go to save, the majority of our customers use Windows file servers. On a Windows file server, the only application to give an open file message is Apple Works.

    I have been working with a senior Apple Engineer on the Xserve project to get Apple to understand that in a multi-user / multi-platform environment, this is a dangerous feature.