Flat file problem

BigJohn

I understand using a flat file for a database is not always such a good idea, but for fairly simple things I've had good luck using them. Recently I developed a simple poll for my website using a flatfile to store the users answers. However, I have encountered a problem with this one and can't for the life of me figure out the cause. In my test, I have 9 lines of data in my txt file with each line containing 37 answers separated by commas. The string length of each line is approximately 400 with the total length of the 9 lines of 3515. Now when a new line of data is submitted via the form, it adds the data correctly to a new top line, BUT deletes most, but not all, of the last line in the txt file.

Here is my code and would appreciate some help in making it work.

<?php>
$data = $_SESSION['userfull'].',';
$data = $data .$_POST['B1'].','.$_POST['B2'].','.$_POST['B3'].','.$_POST['B4'].','.$_POST['B5'].','.$_POST['B6'].',';
$data = $data .$_POST['B7'].','.$_POST['B8'].','.$_POST['B9'].','.$_POST['B10'].','.$_POST['B11'].','.$_POST['B12'].',';
$data = $data .$_POST['B13'].','.$_POST['B14'].','.$_POST['B15'].','.$_POST['B16'].','.$_POST['B17'].','.$_POST['B18'].',';
$data = $data .$_POST['B19'].','.$_POST['B20'].','.$_POST['B21'].','.$_POST['B22'].','.$_POST['B23'].','.$_POST['B24'].',';
$data = $data .$_POST['B25'].','.$_POST['B26'].','.$_POST['B27'].','.$_POST['B28'].','.$_POST['B29'].','.$_POST['B30'].',';
$data = $data .$_POST['B31'].','.$_POST['B32'].','.$_POST['B33'].','.$_POST['B34'].','.$_POST['B35'].','.$_POST['age'].',';
$newdata = $data .date("m/d/Y h:i A");
$newdata = nl2br($newdata);
$newdata = stripslashes($newdata);

$file = 'entries.txt';
$olddata=file_get_contents($file);
$newdata = $newdata."\n".$olddata;
$fp = fopen($file,'w+');
$write = fwrite($fp, $newdata, strlen($newdata));
$close = fclose($fp);
?>

bradgrafelman

I hate to beat what may be a rather deceased horse, but I really would be remiss if I didn't first ask you why you aren't using a DBMS (such as MySQL) for this.

However, as for your current issue, note that the 'w+' mode on the [man]fopen/man manual page truncates the file to zero length.

BigJohn

Thanks for the quick response. I guess I don't know what the "truncates to zero length" means but thought by adding the strlen($newdata) to the fwrite would do the trick. Obviously it didn't help. Would using the r+ rather than the w+ resolve the issue?

I don't use databases very often but have done a little with MySQL. For this poll, which is on a password restricted site with only a few members, the flatfile seemed a natural.

bradgrafelman

BigJohn;10992811 wrote:
I guess I don't know what the "truncates to zero length" means

For that, you'll need a different manual - the one for the English language. The key word there is truncate.

BigJohn;10992811 wrote:
but thought by adding the strlen($newdata) to the fwrite would do the trick.

Do what "trick" ? As soon as you call fopen() with a mode of 'w+', the entire contents of the file is lost.

Why would giving fwrite() a value for an optional parameter (one that simply tells it when to stop writing) have any effect on the previous data in the file?

BigJohn;10992811 wrote:
Would using the r+ rather than the w+ resolve the issue?

Did you read the manual for [man]fopen/man and decide if the description for the 'r+' mode best fits what you're trying to do? If so, then it probably will. If not, then it probably won't.

BigJohn;10992811 wrote:
I don't use databases very often

Well then it sounds like you've got a perfect candidate task/project to use as a learning experience.

Weedpacket

bradgrafelman wrote:
Well then it sounds like you've got a perfect candidate task/project to use as a learning experience.

I agree, although setting up a full DBMS for this project may be overkill. This sounds like an ideal time to become acquainted with [man]SQLite[/man].

Bonesnap

If you insist on not using a database like MySQL and want to use a "single file", put your data into an XML file. At least it will be better organized and easier to read.

johanafm

bradgrafelman;10992809 wrote:
note that the 'w+' mode on the [man]fopen/man manual page truncates the file to zero length.

But since he's writing both the new contents and all of the new contents, that shouldn't matter.

BigJohn;10992808 wrote:
it adds the data correctly to a new top line, BUT deletes most, but not all, of the last line in the txt file.

The only thing I can think of that might cause weird behaviour like this is race conditions. In the end, if this might be the cause, that would depend on how the operations fopen with w+ and file_get_content works. For example, assuming that truncate to zero length is atomic while file_get_contents is not and doesn't use locks, then if one user starts reading with file_get_contents, reads most of the file and then another user initiates an fopen w+ and truncates the file, suddenly there is no more data to read from the file.

Do note that this only has to happen once. At that point, you will always have a non-complete ending line at the point it was originally cut off.

Or does this happen every time you run the script?

Either way, I strongly recommend you do as suggested and start using a DB. They are built to handle things like this with concurrent operations. If not, at least instead leave the original contents in the file and append the new stuff to the end.