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 -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel