#50218 [Opn]: flock() has numerous documentation errors

ID: 50218 Updated by: danbrown@php.net Reported By: shelby at coolpage dot com Status: Open Bug Type: Documentation problem Operating System: All PHP Version: 5.3.0 New Comment: == KEY: > Your Comments My Responses == > In the meantime, you have many errors in > those user comments which did get approved > on that page. Talk about future housekeeping! Tell me about it! It's an ongoing effort, and one in which we'd certainly welcome the assistance of someone with as much time available as you're demonstrating in noticing the errors. We're all volunteers who donate our time to the community on a daily basis, and if you'd like to join the ranks to offer your assistance in making things better for your fellow PHP developers, it would be greatly appreciated! > Dan you have no point and no logic. But you > are good at destroying effort and chasing > away the people who do apply inspired effort. Aww, when you say it, it hurts. Previous Comments: ------------------------------------------------------------------------ [2009-11-18 16:45:35] danbrown@php.net == KEY: > Your Comments My Responses == > Dan Brown I had already read the submission > guidelines for manual annotations, and in > fact my notation repeats some of the other > notations already on the manual page (e.g. > that LOCK_NB is a binary flag option that > can be combined with options). > > Removing my note from the manual page, > means that others will spend a whole > day of frustration trying to figure > out what I figured out, for as long as > the manual is not fixed, which who > knows might be months or even years. Not true. When a documentation bug is submitted, it is usually resolved within 72 hours. So until you know for a fact how the timing and patterns work, either join the project or don't make assumptions in how we operate, or question why we do things the way we do, thanks. > So you preference is to deny the users > the information, because they surely > won't find this bug report in meantime? My preference is to maintain a good, solid reliable presentation, and not to confuse others with conflicting or redundant information. When a documentation bug is fixed, it's not normal procedure to then sift through every annotation on the corresponding manual entry to ensure that we've updated it. One could only imagine the effort that would take. However, your estimation as to the intelligence of your peers and their ineptitude at tracking down relevant information is interesting to me. Have you frequently found yourself in situations where you are the only one with enough sense to help yourself? If you pass judgment as to the ability of those around you, my guess is that you'd find yourself quite lonely in many circles. > I put a link here in the bug report, so > who ever fixes the bug, can send an email > to the note editor to remove my note later. Links don't work that way, Shelby. They direct you TO a page, they do not report back FROM the target. So this is baseless. > Your premature deletion of my note did not > save any housekeeping effort on your part, > it merely destroys my work and hides the > information from the millions of PHP users. It was not premature, and in fact did serve its purpose in housekeeping. Further, please check your metrics, as "millions of PHP users" would be fantastic, but I think may be a bit exaggerated in this case. > Shame on you Dan Brown. At least you > had the dignity to post here what you > had done, so I can reply to you. Dignity is the one thing I didn't have to sacrifice on my wedding day. Now, if we were to discuss other things like personal space or sanity.... > Waste my time once, but never again. I > will withhold my contributions from PHP > from here out. It's worth noting that, within a few moments, you posted a follow-up on this report. Perhaps you meant this promise to be appended to the end of that message. > Congratulations. Thank you. It's been a long, difficult journey, but we appreciate your support. We'd like to thank the Academy.... ------------------------------------------------------------------------ [2009-11-18 16:32:22] shelby at coolpage dot com In the meantime, you have many errors in those user comments which did get approved on that page. Talk about future housekeeping! Dan you have no point and no logic. But you are good at destroying effort and chasing away the people who do apply inspired effort. ------------------------------------------------------------------------ [2009-11-18 16:25:49] shelby at coolpage dot com Dan Brown I had already read the submission guidelines for manual annotations, and in fact my notation repeats some of the other notations already on the manual page (e.g. that LOCK_NB is a binary flag option that can be combined with options). Removing my note from the manual page, means that others will spend a whole day of frustration trying to figure out what I figured out, for as long as the manual is not fixed, which who knows might be months or even years. So you preference is to deny the users the information, because they surely won't find this bug report in meantime? I put a link here in the bug report, so who ever fixes the bug, can send an email to the note editor to remove my note later. Your premature deletion of my note did not save any housekeeping effort on your part, it merely destroys my work and hides the information from the millions of PHP users. Shame on you Dan Brown. At least you had the dignity to post here what you had done, so I can reply to you. Waste my time once, but never again. I will withhold my contributions from PHP from here out. Congratulations. ------------------------------------------------------------------------ [2009-11-18 13:55:15] danbrown@php.net For the record, I rejected your note from the manual page. It's enough to have this bug report in place, and is unnecessary to append a note to the page as well. It just leaves more housekeeping for later. ------------------------------------------------------------------------ [2009-11-18 13:34:33] shelby at coolpage dot com Note the link in the above bug Description, to my annotation at the flock() manual page, was incorrect and should be: http://www.php.net/manual/en/function.flock.php#94682 I have summarized the issues there: * LOCK_NB does work on Windows, only the wouldblock argument is not supported. * LOCK_NB option may be combined with the other LOCK_* options, which may not be combined with each other. * May be used with NFS because implementation uses fcntl. * Locking is mandatory in some cases in addition to Windows. * OS with Posix.1 compliant fcntl will release all a scripts' flock()s on a file, if that same script fclose() any file handle on that file. * Do not confuse the LOCK_* values (1,2,3,4) input to this function, with the LOCK_* OS values (1,2,4,8), even though their semantics are similar. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/50218 -- Edit this bug report at http://bugs.php.net/?id=50218&edit=1