Jens Alfke <mailto:j...@mooseyard.com> wrote (Sunday, May 30,
2010 9:51 AM
-0700):
On May 30, 2010, at 7:57 AM, James Bucanek wrote:
When a change occurs, I attempt to open the file using the FS API specifying
exclusive read + exclusive write access. If it fails, it's
likely because some other process still has the file open. I delay a half
second or so and try again.
That sounds like a good approach, but it’s not 100% reliable. If the creating
process opened the file without requesting an exclusive lock, then your open
call will succeed even though the file is still open.
It isn't 100%, but not for that reason. When you call FSOpenFork
and specify fsWrDenyPerm, it will fail if another process
currently has that fork open for writing. The other process does
not have to request exclusive write access, just write access,
which is probably the case for a file that's being written. From
the API docs for fsWrDenyPerm: "... the path cannot be opened if
you request deny-write permission, but some other path already
has write access."
It isn't "100%" because not all volumes support deny-read and
deny-write modes. See bHasOpenDeny.
--
James Bucanek
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
