Hi,
Well, locking a file with flock() doesn't mean that a lock is actually created at the os level.
flock():
On many platforms (including most versions or clones of Unix), locks established by flock() are merely advisory. Such discretionary locks are more flexible, but offer fewer guarantees. This means that files locked with flock() may be modified by programs that do not also use flock(). Windows NT and OS/2 are among the platforms which enforce mandatory locking.
So, what you're seeing with the risk of corruption is really documented unfortunately.
Take a look at the File Locking Tutorial which will give you a solid base of how the locking is done
Also, take a look at the MTA program documentation. sendmail's locking scheme:
it does recognize its own locking system, which consists of a mboxname.lock file in the same directory as the mbox. -- ishamael (RE: File Locking)
update: Come to think of it, using a progname.lock locking mechanism on unix/linux is very common. Depending on the program you are interacting with (i.e. sendmail), you might be able to get away with flock, a .lock file or similar. You will have to research the program to determine if when the .lock file is created, does the program automatically assume that it can write to the file regardless if the program itself did not create the .lock file?
Hope this helps
Jason L. Froebe
No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1
In reply to Re: 5.8, locking with IO::File and Fcntl
by jfroebe
in thread 5.8, locking with IO::File and Fcntl
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |