Mark Manning/Muniz Eng. (mark@cheers.jsc.nasa.gov) said: >NOW - BEFORE I SAY ANYTHING >>>>THIS IS JUST CONJECTURE ON >MY PART<<<< and not something I read which some Apple >person posted. So this is just pure "What IF"! Ok? OK. I think I can clarify some. >Let's suppose that the OPEN statement opens an I/O >channel. Ok - not too hard to do. > >Let's suppose that the OPEN statement tells the Mac System >to provide an exclusive lock on the file so no one else can >talk to the file. Sort of. When you open the file (one of its forks, actually), you can tell the File Manager whether you want to read from it, write to it, or both. You can also tell the File Manager whether other applications can open the same file (fork) for reading, writing, or both. Typically, you open the file in one of two ways: read/write for you and nothing for others, or read-only for you and read-only for others. Both of these combinations prevent one application from writing to a file while another is trying to read the same file. >Let's suppose that the SetFileInfo command also opens an >I/O channel. > >Let's also suppose that the SetFileInfo command also >attempts to open the "exclusive lock" file. It doesn't need to get that complicated since SetFileInfo does all of its work in a single, simple call (as opposed to reading and writing which may take many calls, so you need an Open call to build up state, and a Close call to release it). Internally, the File Manager _does_ need to synchronize that SetFileInfo with other calls that may want to access the same file or same volume. In the case of Mac OS, the File Manager (generally) only processes one call at a time, so it doesn't really have to worry about two calls trying to modify the same data at the same time. -- Mark Day, mday@apple.com Mac OS Filesystem Engineer Apple Computer, Inc. ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch