Форум PHP

Проблема не одного скрипта и не одного случая. Классическая система разметки базового файла имя|время|сообщение|ответ\r\n первое что было это гостевая. Потом данную систему применял в других целях (новости, блоги и пр.) оперировал я этими строками из админки через сценарий

$basestr = file("$base");?     $restr = trim($basestr[$str]);?    $buff = @file_get_contents($base);?    $buff =str_replace("$restr\r\n","$restr|$otv\r\n",$buff);?    $file = fopen("$base","w");?    fputs($file,"$buff");?    fclose($file);?

$str - номер строки которую передавал через ссылку ответить в админке. В данном случае добавился к строке ответ админа. Таким же образом удаляю строки $buff =str_replace("$restr\r\n","",$buff);?работает это в 99% но попадется одна на сотню строка какую не удалить, не ответить. Искал взаимосвязь с спецсимволами в строке. Но ее нет. Все что опасно я обработал. А зависание происходит даже на пару слов в строке. Вот что на зависание пишет cpanel..

... Куда приходиться лезть для избавления от глючной строки. > file1.txt File type: UTF-8 Unicode text, with CRLF line terminators. Что это за глюк, откуда он возникает и как с ним бороться?

Вот еще пример возмущения на глюк > fatal error or timeout occured while processing this directive. Насчет последнего не уверен что связано с той самой глючной строкой но все же может наведет на мысль более знающих особенности файловых систем и Apache.

Я поражен. Первый раз не нахожу ответа на этом форуме. Видимо недостаточно точно сформулировал вопрос. Ну да ладно буду сам искать причины.

Файл лочите? Т.е. используете flock() для предотвращения одновременной записи в него нескольких потоков?

Нет. Если необходимо то попробую.

Файлом пользуется лишь один пользователь или возможно, что несколько человек одновременно в него пишут? Если последнее утверждение верно - то проблема именно в этом... Базы данных используют не просто так - они создают очередь запросов в оперативной памяти и автоматически снимают с разработчика заботу об одновременном доступе к файлу на диске. При работе с файлами это всё ложиться на вас - при существующем подходе один поток открыл, файл, другой поток открыл файл, оба что-то записали, оба закрыли. Учитывая что вся записываемая информация в файл ложиться из оперативной памяти в момент его закрытия - может быть масса неприятностей - в том числе и полная потеря информации в файле.

Файлы сейчас применяют только в одном случае - с ними в каждый момент времени работает только один человек (как правило, администратор) - во всех остальных случаях стараются использовать СУБД, которая берёт на себя все эти проблемы.