| First, I am assuming that calls like PBOpenForkSync do not block when a requested deny mode cannot be immediately fulfilled by the VFS. For example: FSForkIOParam pblock; memset(&pblock, 0, sizeof(pblock)); pblock.ref = &theRef; pblock.permissions = fsWrDenyPerm | fsRdWrPerm; pblock.forkNameLength = dataForkName.length; pblock.forkName = dataForkName.unicode;
err = PBOpenForkSync(&pblock);
err = permErr if the process can't obtain the proper deny mode.
For POSIX opens: int fd = open( path, O_SHLOCK | O_RDWR ); the open call should block until the lock can be obtained.
The blocking behavior is opposite. However, when a VFS gets these calls, PBOpenForkSync does not set O_NONBLOCK in the open, and the VNOP_ADVLOCK call has the F_WAIT flag set. This appears to be a bug in the core foundation / carbon layer interface with BSD because a VFS implementor can't tell the proper blocking behavior in the VNOP_ADVLOCK call.
It appears that Apple's SMB and AFP clients do not implement POSIX O_SHLOCK and O_EXLOCK semantics properly, since they do not block until such a lock can be obtained even when O_NONBLOCK is not set.
Has anyone seen this before? I believe that the Adobe Acrobat problem on network home folders is caused by the AFP client not blocking on O_EXLOCK properly.
Paul Nelson Thursby Software Systems, Inc.
Note, PBHOpenDenySync appears to call into the VFS the same way PBOpenForkSync does. |