Using flock is not necessarily a portable or guarenteed solution - even from unix box to unix box. If the file is available to two different programs, one using flock and one not, then the non-flock using program will still be able to modify the file even though the flock-using progam locked it:
Not implemented (Mac OS, VMS, RISC OS, VOS).
Available only on Windows NT (not on Windows 95). (Win32)
Two potentially non-obvious but traditional flock semantics are that it waits indefinitely until the lock is granted, and that its locks merely advisory. Such discretionary locks are more flexible, but offer fewer guarantees. This means that programs that do not also use flock may modify files locked with flock.
One advantage of swallowing the SQL bullet and using a proper DBMS is that you can be assured that all access paths to your data are using the same rules for locking. If you really can't use a proper DBMS, for whatever reason, then at least consider creating your files in a directory owned by a special purpose user. Only scripts running as that user will have access to the files and subdirectories and it will be easier to prevent scripts that don't use flock (or misuse it) from writing to the directory.
Getting this to work right and testing it may take some time. If this is a homework project or a "teach myself locking project" then enjoy the learning experience. However, if the main point of this project is to accomplish a goal for a work, personal, or volunteer project, please reconsider. In particular, if your reason for avoiding SQL is that you don't know SQL and you don't want to spend the time learning it, please reconsider. The SQL commands to add, update, and remove records from a simple one table database are not all that hard to learn. Testing the non-SQL solution is likely to take a good bit of time, possibly more than learning the SQL. More importantly, you will be able to use SQL over and over. My guess is that what you learn from writing a special purpose locking solution is unlikely to be as generally useful unless you plan to make a career out of low level file system manipulations.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||