Hi all, I noticed recently that the file locking code in OsFileBase and OsFileLinux is somewhat out to lunch, and doesn't work correctly at all. Fortunately there are very few callers that use the locking code - just two files in sipXpbx, as far as I can tell. Both of them use it to get exclusive locks on files, and don't use the read/write locks that in theory the OsFile API supports now.
So, I've implemented a simpler version of file locking which supports advisory exclusive locking (i.e. write locks), but does not provide read locks. There are two changes I'd like to mention on the list before checking it in to make sure nobody knows of a reason it will cause trouble: 1) It changes the Windows implementation of OsFile::filelock() to return OS_FAILED always, instead of OS_SUCCESS always, since in fact it does not do any cross-process locking. I think this should be OK, because: 2) It changes the behavior of OsFile from always implicitly getting a (broken) read lock to only getting locks when requested (which, again, is almost never). I don't believe that either of the two call sites I found requires the implicit read lock behavior, based on looking at the code. The first change will require somebody to actually write the cross-process file locking code for Windows if they want sipXpbx to work there. Of course, it was already broken - it just was a race condition before, and this would make it a reliable failure. I'll check in the change soon if nobody objects. --Mike Mammarella SIP VoIP, IM and Presence Consulting http://www.sipez.com/ _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
