Over the last few days I've been chasing a frustrating bug which I finally found the cause of. Here's what I was doing (my platform is 32-bit linux):

1. Call FileOpen to get a filehandle with "fmOpenReadWrite OR fmShareExclusive" for the mode. This causes the file to be opened read/write with an exclusive lock. What this equates to under the hood is a syscall to "open" and another syscall to "flock" with "LOCK_EX or LOCK_NB" for the lock flags. This does cause the advisory lock to be placed.

2. Close the file with FileClose.

3. Immediately call FileOpen again on the same file.

What I would see is that FileOpen would return a -1, and FpGetErrNo would return 11, EAGAIN. After stepping down through the RTL code, I determined that although FileClose would indeed close the file descriptor, the advisory lock (viewed through /proc/locks) for that handle would still exist. Then, the subsequent call to the open syscall happened to be returning the same file descriptor (the man page for "close" does indicate that that can happen). Then, FileOpen's call to DoFileLocking would fail in the flock syscall because the lock actually still does exist for that file descriptor.

I solved to problem by adding this to my code right before the close:
   Unix.FpFlock(myFD, LOCK_UN or LOCK_NB);

This forced an explicit unlock. Then the open/flock calls would both succeed.

My question is this: if FileOpen automagically handles the file locking through a call to DoFileLocking, wouldn't it be more correct for FileClose handle unlocking as well?

Thanks,

-SG

Seth Grover wrote

My question is this: if FileOpen automagically handles the file locking through a call to DoFileLocking, wouldn't it be more correct for FileClose handle unlocking as well?

It should, if it's necessary.

Interestingly

"man 2 flock" says:

|Furthermore, the lock is released either by an explicit LOCK_UN operation on
|any of these duplicate descriptors, or when all such descriptors have been |closed.

So I would expect the lock to disappear when the file is closed. Nitpicking people might say, this only applies to duplicated descriptors, but then what's the point?

So, actually I'm inclined to consider that a bug in the underlying OS.

Vinzent.

I tend to agree with this. The reason the explicit unlock is not done is that the close should do it implicitly (as per the man page).

But are you sure the first close() operation actually succeeded ?

Michael.