Если в кратце, то суть такая: file_put_contents() не атомарен и не гарантирует записи данных файл, а может вообще очистить его содержимое так и не записав новое содержимое.

Синтаксический сахар это хорошо. Судя по описанию, функция file_put_contents() идентична последовательным успешным вызовам функций fopen(), fwrite() и fclose(), что влечёт за собой некоторые особенности, связанные с этими функциями. Сразу скажу, что пробовал воспроизводить это только внутри Docker контейнеров и утилизацией диска близкой к 100%, возможно в другом окружении такое поведение воспроизводиться не будет. Для начала давайте с умным видом  посмотрим исходник PHP 7.1.12.

Собственно, какие шаги можно увидеть?

  • открывается файл (php_stream_open_wrapper_ex) по-умолчанию в режиме w, что производит очистку файла! Флаг FILE_APPEND открывает файл в режиме a, но этот кейс не рассматриваем.
  • если передан флаг LOCK_EX, то файл открывается в режиме c и дополнительно очищается (php_stream_truncate_set_size)
  • что-то пишется в файл (php_stream_copy_to_stream_ex || php_stream_write)
  • файл закрывается (php_stream_close)

А что, если скрипт прервётся (например, kill, Control + C, reset) после открытия файл в в режиме w, либо в режиме c после php_stream_truncate_set_size, но не дойдя до php_stream_copy_to_stream_ex  или php_stream_write? Правильно, файл останется абсолютно пустым! Т.е. вызывая функцию file_put_contents() существует вероятность получить абсолютно пустой файл, вместо его предшествующего содержимого.

Такую же ситуацию можно получить, если вызывать поочерёдно fopen(), fwrite() и fclose(). На вскидку приходит несколько способов защиты от такого побочного эффекта.

Во-первых, не пользоваться для сохранения значимых данных файлами. Гораздо надёжнее использовать полноценные СУБД с их атомарностью в рамках транзакций, что защитит даже от внезапной остановки сервера, при условии использования журналируемой файловой системы, либо InnoDB Doublewrite Buffer в MySQL и его аналогов в других СУБД. Как вариант, можно рассмотреть NoSQL и Key-Value решения, в случаях остановки PHP скрипта они защитят от потери данных. Но, для случаев внезапной остановки сервера нужно изучить их работу.

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

В-третьих, можно воспользоваться таким кодом:

$fp = fopen($file, 'c');
$result = fwrite($fp, $value. '$');
ftruncate($fp, strlen($offset) );
fclose($fp);

Обратите внимание на открытие файла в режиме c.

Если файл существует, то он не обрезается (в отличие от ‘w’), и вызов этой функции не вызывает ошибку (также как и в случае с ‘x’). Указатель на файл будет установлен на начало файла.

Затем поверх старого содержимого пишется новое содержимое. Т.к. новое содержимое может быть короче, чем старое, нужно как-то дополнительно пометить конец данных, для этого в моём примере используется ‘$’, что является последовательностью символов 100% не входящую в полезные данные. После чего файл обрезается до длины полезных данных. А теперь рассмотрим этот алгоритм пошагово.

  • файл содержит данные: 1234567
  • открывает файл на запись и помещаем указатель на первый символ
  • пишем в файл новые данные: 890 + $
  • в файле оказывается содержание: 890$567
  • обрезаем файл до длины полезных данных, т.е. до 3-х символов
  • в файле оказывается содержимое 890
  • закрываем файл

Такой подход защищён от резкого останова скрипта. Даже если он будет остановлен между 4 и 5 шагами, можно будет в момент чтения отсечь лишние данные начиная с $ символа. При резком отключении всего сервера возникает 2 ситуации, в зависимости от журналируемости файловой системы. Если она не поддерживается или отключена, то в файле может оказаться неконсистентное состояние. Но если журналирование включено, то в файле останется последнее консистентное состояние.

В одной из библиотек на github нашёл такой вариант решения проблемы:

/**
 * Atomic filewriter.
 *
 * Safely writes new contents to a file using an atomic two-step process.
 * If the script is killed before the write is complete, only the temporary
 * trash file will be corrupted.
 *
 * The algorithm also ensures that 100% of the bytes were written to disk.
 *
 * @param string $filename     Filename to write the data to.
 * @param string $data         Data to write to file.
 * @param string $atomicSuffix Lets you optionally provide a different
 *                             suffix for the temporary file.
 *
 * @return int|bool Number of bytes written on success, otherwise `FALSE`.
 */
public static function atomicWrite($filename, $data, $atomicSuffix = 'atomictmp') {
    // Perform an exclusive (locked) overwrite to a temporary file.
    $filenameTmp = sprintf('%s.%s', $filename, $atomicSuffix);
    $writeResult = @file_put_contents($filenameTmp, $data, LOCK_EX);

    // Only proceed if we wrote 100% of the data bytes to disk.
    if ($writeResult !== false && $writeResult === strlen($data)) {
        // Now move the file to its real destination (replaces if exists).
        $moveResult = @rename($filenameTmp, $filename);
        if ($moveResult === true) {
            // Successful write and move. Return number of bytes written.
            return $writeResult;
        }
    }

    // We've failed. Remove the temporary file if it exists.
    if (is_file($filenameTmp)) {
        @unlink($filenameTmp);
    }

    return false; // Failed.
}

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *