On Windows, there is no such thing as a true open-write-for-append. Unlike Unix, write for append mode is not atomic, internally it is a seek + write. Mix that with multiple writers, and you have an inherent race condition built it.
Richard Quadling wrote: > That's good news. Has a patch been submitted? Even if it is initially > only a win32 compiler directive wrapping the lock? > > On 14/04/07, Rob Richards <[EMAIL PROTECTED]> wrote: >> I can sometimes reproduce the missing entries though never get data >> corruption anymore. >> This might now be a Windows only issue with how it is caching writes. I >> did a little debugging and no errors occurred. >> The file was opened successfully every time, the data was written >> (correct number of bytes as well) every single time, but depending upon >> the load on my system at the time it was a crap shoot whether every >> single write actually made it into the physical file or not. Adding a >> lock here did resolve it so that it worked 100% of the time. >> >> Rob >> >> Richard Quadling wrote: >> > So why are there missing entries? >> > >> > I can even get the corruption back again if I use a shorter line (100 >> > rather than 5000). >> > >> > >> > On 13/04/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote: >> >> The new implementation does not use any locks, instead it uses direct >> >> io, where locks are not necessary for append operations. >> >> >> >> >> >> On 13-Apr-07, at 6:33 AM, Richard Quadling wrote: >> >> >> >> > On 05/04/07, Rob Richards <[EMAIL PROTECTED]> wrote: >> >> >> No difference using sprintf()/fwrite() instead of fprintf(). >> >> >> >> >> >> I did come across a similar issue from apache: >> >> >> http://mail-archives.apache.org/mod_mbox/httpd-dev/199503.mbox/% >> >> >> [EMAIL PROTECTED] >> >> >> >> >> >> Changing to use VCWD_OPEN_MODE, write() and close() seems to work. >> >> >> >> >> >> Rob >> >> >> >> >> > >> >> > Using PHP 5.2.2RC2-dev (cli) (built: Apr 13 2007 04:03:02) on >> >> > Windows with >> >> > >> >> > for %x in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do >> >> > start php -r "ini_set('error_log','/tmp/test.log');for($i=0;$i<1000; >> >> > $i++)error_log(str_repeat('%x',5000));"`; >> >> > >> >> > And then doing some analysis of the log file I'm finding that not >> all >> >> > the data has been written. >> >> > >> >> > Array >> >> > ( >> >> > [A] => 4965993 >> >> > [B] => 4590918 >> >> > [C] => 4525905 >> >> > [D] => 4695939 >> >> > [E] => 4495899 >> >> > [F] => 4710942 >> >> > [G] => 4495899 >> >> > [H] => 4645929 >> >> > [I] => 4540908 >> >> > [J] => 4580916 >> >> > [K] => 4535907 >> >> > [L] => 4470894 >> >> > [M] => 4480896 >> >> > [N] => 4550910 >> >> > [O] => 4610922 >> >> > [P] => 4500900 >> >> > [Q] => 4630926 >> >> > [R] => 4480896 >> >> > [S] => 4500900 >> >> > [T] => 4535907 >> >> > [U] => 4630926 >> >> > [V] => 4470894 >> >> > [W] => 4645929 >> >> > [X] => 4825965 >> >> > [Y] => 4845969 >> >> > [Z] => 4920984 >> >> > ) >> >> > Lines (Should be 26 * 1000) : 23973 >> >> > Longest (Should be 5024) : 5024 >> >> > Shortest (Should be 5024) : 5024 >> >> > >> >> > Out of the 26,000 lines expected we are missing 2027 lines. >> >> > >> >> > So no corruption of the lines, just missing ones. >> >> > >> >> > The only explanation I can think of is that the locking is working, >> >> > but nothing is waiting for the lock to become available. >> >> > >> >> > Richard. >> >> > >> >> > >> >> > -- >> >> > ----- >> >> > Richard Quadling >> >> > Zend Certified Engineer : http://zend.com/zce.php? >> >> > c=ZEND002498&r=213474731 >> >> > "Standing on the shoulders of some very clever giants!" >> >> >> >> Ilia Alshanetsky >> >> >> >> >> >> >> >> >> >> >> > >> > >> > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
