Нужно. Если вы читаете файл и намереваетесь внести в него изменения на основе прочитанных данных, вам нужно быть уверенным, что другие процессы в этот момент не прочитают устаревшие данные. В этот момент вы должны читать именно с исключительной блокировкой, что и сделано в ExBB. Обратите внимание, что сейчас в ядре форума присутствуют 2 метода чтения: _Read() и _Read2Write(), и какая блокировка используется в каждом из них.


Вот вы утверждаете, что:


но при этом кидаете ссылки на сайты в стиле "файловый архив студентов" вместо официального мануала. Что-то, по итогу, в утверждение о детских штанишках слабо верится...


Отвечу вам вашей же фразой:




А с чего вы это взяли? Работать с базами данных в чём-то даже удобнее, чем с файлами. Возьмите тот же phpMyAdmin. Работать с его графическим интерфейсом (где уже встроены инструменты для фильтрации и сортировки данных, где данные отображаются в виде наглядных таблиц, где создание резервных копий и восстановление из них доведены да автоматизма) будет уж точно лучше, чем колупаться в ваших файлах в текстовом редакторе, отыскивая разделители полей (ваши палочки - |) и подсчитывая по индексу, что означает то или иное поле. Другое дело БД, где все поля подписаны.


4 человека, залётные гости и поисковые боты. Большинство форумов ExBB в Интернете заброшены и, либо ещё сами кое-как поддерживаются силами пользователей, либо уже сконвертировались на другие движки. Я знаю от силы штук 10 форумов на ExBB, которые состоялись (собрали более 10к сообщений), остались на ExBB и при этом на которых продолжают общаться люди. Остальное - полумёртвые и мёртвые висяки типа http://tvoyweb.ru/forums и т.п.


Если бы вам нужен был форум, вы бы давно уже поставили его. Но вам нужен гемор видимо на самом деле, а не форум. И когда вообще для переноса базы данных нужно было знать язык SQL? Да на том же YouTube достаточно мануалов по переносу базы через phpMyAdmin за 4 клика!
Про потерю данных: не знаю ни одного случая, когда именно MySQL становился причиной потери. Относительно новое журналируемое хранилище InnoDB обеспечивает сохранность не хуже, чем те же файлы. Ну а если проблема будет в потере питания или повреждении накопителя, тот тут уж вам ничто не поможет, кроме резервных копий.
Но даже тут у MySQL преимущество. Если какая-то запись в момент пропадания питания не до конца допишется в файл, MySQL сможет автоматически либо восстановить запись из журнала, либо (если в журнале запись не сохранилась) откатить изменения. При этом база приводится в целостное рабочее состояние. С вашими же файлами, если питание пропадёт аккурат на работе fwrite (например), то файл окажется битым, и пока пользователь вручную не исправит его, нормальная работы с ним будет невозможна.


Дискриминировали устаревших динозавров. PHP разрабатывают сотни человек, целое сообщество не самых глупых людей. В отличие от... И наверное есть причина, почему так сделали.


Вы уже полгода, с мая месяца, тут мусолите сообщения, а на выходе у вас получается не лучше, чем уже было здесь 10 лет назад в ExBB. Может с вашей точки зрения названия у функций в вашем варианте красивее, и данные по файлам тоже лежат красивее, но людям всё равно. Открою вам секрет: обычные пользователи в файлы вообще не заглядывают. Они смотрят на функционал и оформление конечного продукта.


На вобле говорите? Бедный http://imho.ws, работает уже 15 лет и не парится, а вы тут страхи рассказываете...


Эй, все слышали? Налетай-торопись! И как мы раньше жили без версии 10-летней с правками в представлении от Flat! Переименуем функции, слегка изменим файлы и тогда-то уж точно заживём!

Неверно сделано. _Read более менее нормально сделали, а с _Read2Write так не получилось. Из старой версии рожки растут.

Прекрасная лаба. там всё верно.

Так и я могу сделать отображение в приемлемом виде в админке. Не вопрос.
Только и так всё понятно, и кж понятней чем сериализированные данные.

Да я что только не ставил..

Давайте про mysql не будем, меня это вообще не интересует, честно.
Ошибаетесь. Предложенная реализация подразумевает запись на старое место, и в коде движка будут предприняты все меры для того, чтобы размер файла при перезаписи сохранялся, исключением те файлы в которых записи редактируются. При добавлении потери не будет в принципе, так как старый файл сохраняется на своём старом месте. При перезаписи к примеру нескольких полей, таких как время последнего посещения можно сохранять длину записи и писать поверх старых данных. В этом случае, даже если сервер грохнется то весь файл останется цел, за исключением возможно повреждённой этой записи, и то не факт.
Что касается редактирования, то тут, конечно риск есть, но тут можно вернутся к темп файлу конкретно для данного случая. Редактируются файлы прямо скажем не часто.

Не надо разводить священные войны. Это вопрос религии.
Я достаточно знаю, чтобы судить что такое ООП на самом деле.

С этим будет получше. Один только вывод сообщений чего стоит: со времён дос наверно.
Обычные пользователи сидят на других движках. А на подобных этому сидят в основном те, кто хочет покопаться своими ручками. Жигули и мерседес: в одном сами копаются, а другой отдают в сервис-центр. Каждому своё. Мне нравится всё держать под собственным контролем.

Он ещё не набрал критическую массу..

Во-первых, повторяю: делаю исключительно для себя, так как нужно лично мне. А другие могут использовать то, что я наваял если захотят.
Во-вторых, я считаю, что код старой версии был испорчен, и испорчен был сознательно. О причинах умолчим..
Да, некоторые вещи исправили, но заложили много подводных камней.
Я уже говорил, что эволюцию старого движка надо было продолжить в том же ключе, исправив мелкие недочёты, может быть кое что изменив. Однако этого не произошло. А те, кто продолжал заниматься старой версией даже не удосужились исправить тот основной баг с обнуление файлов, которые были практически у каждого кто пользовался тем движком. А движок то был хороший, простой и понятный.

Примеры, что конкретно неправильно? И почему же этот форум столько лет прекрасно работает, а у вас эпитеты "более менее нормально" и "не получилось".


Ага, т.е. вам мало написать своё некое подобие СУБД, вы собираетесь к ней ещё и некое подобие phpMyAdmin делать? И сколько лет это займёт?


Файлы редактируются чаще, чем вы думаете. Возьмите и добавьте запись в начало файла. Вы получите полную перезапись. Байки про "запись на старое место" даже не знаю, откуда вы берёте. Такая запись возможна, если вы работаете с файловой системой напрямую, на уровне её драйвера или ядра ОС. В остальных случаях вы вообще никак не можете быть уверены, каким образом файл будет физически сохранён на накопителе. Более того, системные утилиты ФС, та же defrag, могут изменять это хранение, и вы на это никак не повлияете.

Ваше решение с tmp-файлами годится разве что для создания бекапов файлов, но никак ни для рядовой работы с ними, т.к. при перемещении/переименовании файлов сразу слетит установленная ранее блокировка, и вам нужно будет использовать другой механизм синхронизации процессов для предотвращения повреждения данных.


Судя по вашему коду, он старше минимум на 14 лет вашего опыта работы с PHP. И ещё спокойно столько же лет прекрасно проработает.


Ну наконец-то я слышу "хороший, простой и понятный". Что и требовалось доказать. Свою полемику я начал именно с того, что вы довольно часто в своих сообщениях не очень лестно отзываетесь о том, что было сделано до вас. При этом своего толкового (и главное рабочего) вы так до сих пор ничего и не предложили. Я считаю, что стоит с пониманием и уважением относиться к чужому труду, тем более что ваша работа всё равно так или иначе на нём основывается.

1. Не нужно было размазывать по разным функциям открытие-закрытие файла. Да ещё делать массив для хендлов файлов. Бред отборный. Элементарно можно забыть закрыть файл через тонну кода. Правильней делать это всего-лишь в одной функции.
2. Функция _Read2Write читает файл с исключительной блокировкой. Это не правильно, ещё раз повторю для непонятливых.
Оно вроде как работает, но в один прекрасный момент...

Я писал, что могу это сделать при необходимости. однако в планах на конкретный движок у меня этого нет. Я делаю упрощённый вариант. Кстати, я тут недавно написал, что беру старую версию и т.п. Не верьте мне. Более вникнул в код старой, там куча мала того что мне не нравится. Сейчас я продолжаю работать над совершенно самостоятельной версией. Т.е. там будет только мой нативный код. Иногда будет проскальзывать общая структура некоторых файлов из существующих версий, однако в целом код полностью переписан с нуля. Много добавлено и много убрано. Мне лично нравится. Вчера делал например обработку формы регистрации. Сегодня делаю обработку формы активации по ключу. Короче говоря занимаюсь регистрацией. В существующем движке регистрация сделана несколько кривовато. Проскальзывают ошибки и баги. Например нашёл такой баг по ходу изучения кода: в exbb не обрабатываются символы Ё и ё вобработчике формы регистрации, по крайней мере в кодировке 1251. Я у себя исправил этот баг. Ну и далее по мелочи много чего.

Почему же? Если открывать файл со спецификатором w то перезапись может быть где угодно, а если с r+ то будет писаться на старое. Я проводил эксперименты по перезаписи, это не фантазии. Можете проверить сами.

Вот это меня тоже насторожило. Поэтому я и отказался от этого переделав функцию. Но как пишут в реальности всё работает..

Мой код прекрасен(для меня) Более того: я его люблю. А во на оопнутый код смотреть не могу. Для меня он быдлокод.

Проблема в том, что я раскидываюсь по сторонам. Сейчас начал более времени посвящать этому, так что возможно скоро будет рабочая вещица..

Ещё добавлю, почему это нужно. В файлы подобного формата информацию можно добавлять со спецификатором a или a+. Это позволяет не беспокоится за основное тело файла, ибо оно не перезаписывается, как это происходит когда приходится сохранять целый сериализированный массив. Поэтому для меня это веское соображение в пользу таких файлов, на чём я и остановился.

1. Если не знать свой id и не видеть последние свои сообщения, то хз как найти ссылку на свой профиль
2. Новая Опера определяется движком как Хром