could not open file for writing

fopen()

[jamie]

hi,

we have an online store which writes an html file to a folder and mails this html file to the buyer. it works 99% of the time, but sometimes it barfs on fopen() and returns an error.

here is the function i am using:

function write_file($file, $data) { 
$fp = fopen("$file", 'w');  
if (!$fp) {  
exit('Could not open desired file for writing');  
return false; 
}  
fwrite($fp, $data); 
fclose($fp);  
return true; 
}

the odd thing is, it works 99% of the time, so i know it is not a directory permissions / safe_mode issue - what could be the cause?

a locking issue, because 2 customers purchased at exactly the same time? i thought fopen/fwrite would take care of that automatically? i have looked in the docs and can't find any inspiration there.

much appreciate any feedback

thanks

[dreamcatcher]

Maybe flock() is what you need?

[uk2.php.net...]

[henry0]

For the same purpose
try
$fp = fopen("$file", "r+");

it works fine and does for my script the job you try to achieve 100% of the time

[jamie]

hi dreamcatcher,

i have wrapped the function with a simple locking file - see if that helps.

something else just occured though - each of the html files have unique names - so it can't really be a locking issue - as each write is to a unique file. hmmm

maybe something else - some ilegal character in the name?

[henry0]

This is the way I do it with multiple files
For each files I grab an ID
you can do the same with a file name
<<
$fp = fopen("$new_file", "r+");
if(!$fp) die ("Hummm cannot open newsletter");

//in ($fp,any #) the number is the precise number of bites from where we start writing data to file
fseek($fp, 59);

$conn = db_connect();
$query = "select id from group_1 where username= '$username' and page= '$page' ";
$result= mysql_query ($query);

while($query_data=mysql_fetch_array($result)) {


$byte = fwrite($fp,$query_data["id"]);
}

>>

[jamie]

hi henry,

thanks for help, but i'm still not sure if that is the right direction for the solution.

my deductions so far:

a) each file has a unique name based on a unique order ID; and each file is distinct per order. this means at no time am i trying to write to the same file from 2 processes - hence it can't be a locking issue

b) the directory has the correct permissions, because nearly all of the time it works - i am unable to duplicate the error myself. from 600 orders it has happened twice.

i can't for the life of me figure out why fopen() should not work on these rare occasions...

...hmmm ;)

[henry0]

When you “say writes a file to a folder” do you mean, creates? As duplicating a template file then open it and write to it.

Is it possible that on two instances because of an unknown script glitch the “writing” was fired before the file was created? or the "writing" was made believe that the file existed?
Do you have a warning such as “Alert! File was not created”?
Do you have a time stamp that allow you to check time of file creation and writing?

Could you at least temporarily add a whole bunch of step checking?
I mean breaking down your process and checking that every step does its job.

[jamie]

hi henry,

those tips are much appreciated - i am going to go through that today. it happened again this morning.

>> When you “say writes a file to a folder” do you mean, creates? As duplicating a template file then open it and write to it.

no, the template is parsed and the result is written to a new file with a unique name - the error comes when the script tries to open this new file for writing fopen($file, w).

the html data to add to the file is created correctly (i mail it to myself in case of error), so it is not a template issue.

>> Is it possible that on two instances because of an unknown script glitch the “writing” was fired before the file was created? or the "writing" was made believe that the file existed?

i am almost cetain no, but is shall check.

>> Do you have a warning such as “Alert! File was not created”? Do you have a time stamp that allow you to check time of file creation and writing?

no - i am going to investigate this now.

cheers henry