[SOLVED] Extremely strange behaviour using FWRITE

[neutra]

Hello guys, I'm new here

And as it appears, I do have a question which neither myself nor Google could answer as of now. So, in hopes this is the right forum, here goes...

 

I have a normal, local textfile that is being opened with fopen in 'w' mode. First off: Due to previous operations, that file contains "blah blah (content here) blubb blah" or something similar. It has been read and parsed, the "content here" note has been replaced with, say, "THE CONTENT", and all this has been saved to a string. You can output that string and it shows up exactly as it should.

Now, when I try to write that same string to that same file (using fopen(w), thus overwriting the file's old contents), it turns out the file still contains whatever it did before! In other words, the file does neither get erased nor get written to at all, it just appears to remain untouched :-\

As I have done intense testing with this so far, you may be certain that:

1. The file exists, is no dir and is writeable

2. The file pointer is valid after the call to fopen()

3. fwrite() gets the correct file pointer and string passed as arguments

4. nothing else ever touches the file, no includes or significant lines further down in the script

 

To test, I simply used the function below instead of fwrite() - however, this is only for debug purposes and using fwrite() "directly" doesn't make any difference...

function testWrite( $fp,$data )
{
   echo "testWrite()  [$fp]   [$data]<br />";
   return( fwrite( $fp,$data ) );
}

 

That test function states clearly that it is going to write the string containing "THE CONTENT" - everything appears correct. However, having a look at the file afterwards shows there hasn't been *any* alteration going on. In fact, the whole thing does seem to work sometimes, but fails rather randomly!

 

Using PHP 4.4.7 on WinXP Pro SP1(local) and Debian Linux(test server), both running apache2 with php as a module (no cgi)

 

I'm totally stuck here. I hope anyone has got an idea...

Thanks in advance!

[neutra]

Quick note: I even tried unlinking the file prior to writing (in this case: recreating) it using fwrite() - makes no difference. It is as if the file was totally immune to changes of any kind oO

[MadTechie]

its probably not being closed..

try this

reboot the server.

then try this script before another test.

<?php
$fp = fopen('thefile.txt', 'w');
fwrite($fp, 'Hello World');
fclose($fp);
?>

[wildteen88]

Your test function works fine for me, full test code

<?php

function testWrite( $fp,$data )
{
   echo "testWrite()  [$fp]   [$data]";
   return( fwrite( $fp,$data ) );
}



$data = 'NEW CONTENT';

$fp = fopen('file.txt', 'w');

if(testWrite($fp, $data))
{
   echo ' - SUCCESSS!';
}
else
{
   echo ' - FAIL!';
}

fclose($fp);

?>

[neutra]

Hi and thanks for your quick answers!

Yes, the file is definitely being closed afterwards. And, since this is from a large project, I cannot really post any excerpt that would be testable for you - except giving away the whole web app, which I'll not (yet) do

 

Unfortunately, I cannot even name the circumstances. I have checked over and over, and though it's a complex system after all, I'm pretty sure there's nothing getting in the way of this particular problem. If that was the case, it probably wouldn't work on random occasions... It does seem to have something to do with what's in the string. My example code was not that realistic as it did not include any HTML - in my "real world" code, the string in question contains HTML taken from a WYSIWYG editor field and looks rather unfriendly. However that shouldn't make any difference at all, right? Am I missing something here? Does anyone probably know of a bug report on php.net concerning fwrite() that might help?

 

 

Thanks for any ideas that might come up...

 

 

 

 

PS. When I get some spare time, I'll try and post a code taken from the app itself, but don't count on it... :-\

[neutra]

Okay, in case it helps, here's some more detail on what's going on in my app.

 

situation: we have a php script which includes 3 iframes. each of these iframes hosts another php script that loads the contents of the frame from a temp file. As you may have figured by now, the iframes are of course WYSIWYG fields (fully editable). When submitting the parent page, all content is ported to a textarea using javascript (I made sure this works as it should). Using something like "print_r( $_POST );" shows that everything is being sent correctly.

 

The following is done by the script receiving the POST data:

 

1. Fetch the default content for each of the three fields from the system config (let's keep it at that, going into detail would be exhausting)

2. For every field, see if there's are corresponding key on the $_POST array and, if so, set the content to that key's value rather than the default value. Works flawlessly.

3. Create a temp file for every field (using an unique filename, of course) and write the field's value to it. This is what fails randomly: Although all the data is where it should be, the file is filled with the default content as specified by the system config. There is absolutely not command initiating this *anywhere*; plus the file should have been fried totally before due to fopen(w).

4. Again display the iframes. The iframe scripts get the filename of the temp file using $_GET and load the content into the iframe. Apparently, if the above fails, it will be the default content as taken from the system config.

 

Point 4 ultimately has the effect of losing the content the user has entered into that field before submitting the form. Strangely, playing drums on the F5 key will get the content back sometimes. Sometimes It even kind of "rotates", as some times only one of the three fields shows the default value, whereas the others manage to fetch the corrrect data. I've made sure that fetching the data from the temp file works, it really is the file itself that contains the wrong data.

 

 

Woah. Any ideas?

[MadTechie]

before i read all that.. what were the results of wildteen88 test?

[neutra]

Oops, yeah sorry, forgot to clarify that.

It did of course work as expected. In my project, I'm using the file system quite often and the error does not occur either, so there's nothing "broken in general", as far as I can see.

Nevertheless, I don't see why, in this particular case, it won't work. Probably I am missing something about stream buffering (just a guess) or there's a bug in php 4.4.7 that has got something to do with what's in the string that should be written to the file. I don't know o.O

[MadTechie]

well 4.4.8 was the last version 4 so it maybe worth upgrading infact php4 has been discontinued for over 5 mouths.. if this is a major project wouldn't it be better to use version 5, as 6 is coming out soon.

 

if you use wildteen88 code as a basis for all the interaction with the files you should be able to find the exact problem.

[neutra]

Yeah, right... since no whatsoever testing managed to solve the problem (nor did the latest PHP4, btw), I found a way to work around it. It seems it's working now...

Thanks for your help and have a nice, bug-free day