Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
OS X Businesses Operating Systems Apple

Open File Locking and Mac OS X? 33

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 discussion has been archived. No new comments can be posted.

Open File Locking and Mac OS X?

Comments Filter:
  • Common to all Unixes (Score:5, Informative)

    by dramage ( 553238 ) on Friday February 21, 2003 @10:27AM (#5352470) Homepage
    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.
  • by Draoi ( 99421 ) <draiocht AT mac DOT com> on Friday February 21, 2003 @10:30AM (#5352494)
    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??
    • by DiSKiLLeR ( 17651 ) on Friday February 21, 2003 @10:36AM (#5352522) Homepage Journal
      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.
      • by Otter ( 3800 ) on Friday February 21, 2003 @10:50AM (#5352613) Journal
        They use fopen(), or they use fstream in C++, or they do it in Carbon or Cocoa in MacOS X....

        ...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.

    • by Anonymous Coward on Friday February 21, 2003 @11:43AM (#5353015)
      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?
      • Mmm yes and relevent point on this:

        You can use "Advisory Locking" (flock()) or "Mandatory Locking" (fcntl() - or lockf(), a front end to fcntl()).

        The advantage of Mandatory locking is that you can choose to lock parts of a file (and leave other parts of it still open to be written to). It also gives you a _fully_ exclusive lock on a file, buy blocking read()/write() systems calls - this is both a blessing and a curse and should be used wisely.

        Advisory locking, however, is much more efficent and is widely supported on all Unixes - unlike Mandatory locking which is not (BSD systems tend to support it out of the box, it's an option with Linux, but much more rarely used - vanilla Red Hat or Debian systems tend not to support it IME).

        Mac OS X developers should note Apple strongly recommend only using Advisory locking and not Mandatory locking.

        Sorry for shouting, but it can be a big deal :-). The issues with Mandatory locking are that it's not supported on all operating systems, and that it's ability to give a truly exclusive lock on a file leads to abusive usage by developers locking files in an abusive - overly harsh (i.e. not even allowing other applications to _read_ the file) - way (not be confused with flocks() ability to simply 'flag' that there is an exlcusive lock).

        I would caution anyone NOT to use Mandatory locking unless they are sure they have a good reason for doing so as I've had problems porting small apps (even Perl scripts!) written by people who've used Mandatory locking when they shouldn't have, it's not difficult to fix, but it can be a pain to track down.

        Due the previous behaviour of Mac OS's file open behaviour I can forgive old school Mac developers from making this mistake (many have a lot on their plate just moving software to Mac OS X) but for Unix developers I think it's pretty inexcusable to screw up completly (by using fcntl() in appropriately or by not checking for advisory locks with flock()).

        Important point:

        If you DO use Mandatory locking you should _always_ check for the existing of advisory locking with flock() *first!*. I think Apple have a man page or technote on this somewhere but it's a big deal if you've ever had your files clobbered by some oaf of a program that doesn't pay attention to Advisory locking :-)
    • by Anonymous Coward
      Surely, it's only good practise when opening a file for write,

      Um, have you ever had anyone edit a Korn shell script underneath you? I would guess not.

  • by peterdaly ( 123554 ) <.moc.mocten.xi. .ta. .yladetep.> on Friday February 21, 2003 @11:56AM (#5353125)
    Apple has quietly entered the groupware collaboration market.

    -Pete
  • Too easy... (Score:5, Informative)

    by mildness ( 579534 ) <.moc.hpmab. .ta. .llib.> on Friday February 21, 2003 @11:57AM (#5353136) Homepage
    "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

  • Big deal (Score:5, Funny)

    by jsse ( 254124 ) on Friday February 21, 2003 @12:06PM (#5353200) Homepage Journal
    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...
  • by Llywelyn ( 531070 ) on Friday February 21, 2003 @12:13PM (#5353269) Homepage
    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.
    • by mithras the prophet ( 579978 ) on Friday February 21, 2003 @02:05PM (#5354425) Homepage Journal
      Having a single process open a file to write, and multiple processes open that same file to read, is obviously not a problem.

      The problem is multiple processes opening a file for write.
  • by exp(pi*sqrt(163)) ( 613870 ) on Friday February 21, 2003 @01:13PM (#5353805) Journal
    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!
  • by 0x0d0a ( 568518 ) on Friday February 21, 2003 @01:20PM (#5353880) Journal
    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.
    • 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.

      WTF? The operating system has no ability to handle this condition and expire locks from dead processes? What year is this?

      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.

      While CVS has its uses, on the operating system level, this is not a solution. Running a CVS server on every system for single-user application work is not a solution, it's just ignoring the problem.

      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.

      Encouraging users to haphazardly write to files and corrupt them does not count as "letting them do the most". Dead apps are no excuse for anything, see above.

  • The sky is falling! (Score:5, Interesting)

    by FunkyMarcus ( 182120 ) on Friday February 21, 2003 @01:29PM (#5353968) Homepage Journal
    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
    • 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.
  • by Anonymous Coward on Friday February 21, 2003 @01:54PM (#5354217)
    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.
  • 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.
  • An older, but still interesting article: UNIX Advisory Locking... [washington.edu]
  • One other major annoyance in OS X is the immutable bit. In MacOS a locked file could be moved or renamed which followed the mac methodology where a file's path wasn't considered constant or used as a reference. Now the opposite bheavior is true.

    To add to the stupidity you can still move or rename a hist directory or non-root volume thus changing the file's path. What a pain in the ass! The ability to lock a file's contents used to be a useful feature Apple!

fortune: cannot execute. Out of cookies.

Working...