Re: NSFileHandle fileHandleForUpdatingAtPath never returns

FROM : Denis Bohm
DATE : Thu May 29 16:47:29 2008

Thanks for the info and tech note reference - using the BSD open call 
with O_RDWR + O_EXLOCK + O_NONBLOCK does just what I was looking for.

On May 29, 2008, at  1:14 AM, Ken Thomases wrote:

> On May 29, 2008, at 1:29 AM, Denis Bohm wrote:
>

>> When another application has a device file open and I try to use 
>> NSFileHandle fileHandleForUpdatingAtPath to open the same device 
>> file, the call just seems to hang and never return.  The API 
>> documentation doesn't say what should happen in this case.  Does 
>> anyone know why it isn't returning?  What I would like is for it to 
>> return with nil or throw an exception...

>
> Cocoa is ultimately using the BSD/POSIX API of Mac OS X to perform 
> file operations.  This file access API can operate in either 
> blocking or non-blocking modes.  From what you describe, I guess 
> it's using the blocking mode.  In your case it's blocking for one of 
> two reasons: the device driver to which the device file provides 
> access can only support one client at a time, or the other 
> application has established an advisory lock on the file and Cocoa 
> is respecting that advisory lock.
>
> See Technical Note TN2037, "Exclusive File Access in Mac OS X" <http://developer.apple.com/technotes/tn/tn2037.html

> >, for an explanation of advisory locking and Cocoa's use of it.
>
> In either case, you may need to use the BSD/POSIX API (e.g. the 
> open() system call) yourself to work around this blocking behavior. 
> Once you obtain a file descriptor, you can then create an 
> NSFileHandle with one of the initWithFileDescriptor:... methods.  Be 
> sure to follow the advice in the above technote and respect advisory 
> locking in your use of the BSD/POSIX API.  Of course, you'll need a 
> strategy for how to handle the failure to open the file because it 
> was already opened by another application.
>
> Cheers,
> Ken
>