cat / dev / null> file.log не врізає великий файл у Дарвіні

Раніше в системах Linux я мав змогу врізати великі відкриті файли журналу (тобто файл, який активно записується процесом) за допомогою cat /dev/null > file.log.

Однак 10.9 (Mavericks), мабуть, це не так. У мене є файл 11 ГБ, який записується в додаток, але коли я виконую ту саму команду з вказаним файлом, схоже, нічого не відбувається.

Коли я спробую це у файлі тривіального розміру, він спрацьовує.

Ось ls -l /dev/null:

crw-rw-rw- 1 root wheel 3, 2 Dec 16 12:49 /dev/null

Я також намагався cp /dev/null file.logбезрезультатно.

Думаючи, що я можу скористатися функцією скорочення ( man 2 truncateу Дарвіні), я скомпілював це і запустив його до двох файлів, одного тривіального розміру, а другого фактичного файлу журналу. Знову ж таки, він працював проти тривіального файлу і не працював на значно більший журнал.

/*
 * Copyright (c) 2013 Thomas de Grivel <thomas@lowh.net>
 *
 * Permission to use, copy, modify, and distribute this software for any
 * purpose with or without fee is hereby granted, provided that the above
 ...
 * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 */

#include <unistd.h>

int main (int argc, const char **argv)
{
        int e = 0;
        while (--argc) {
                argv++;
                if (truncate(*argv, 0)) {
                        e = 4;
                        warn("%s", *argv);
                }
        }
        return e;
}

Процес повертається 0незалежно від того, який файл я використовую.

cat /dev/nullце трохи перекручений спосіб написання команди, яка не дає результату. :або trueє більш очевидними.

У всіх cat /dev/null > file, : > fileі навіть > fileв більшості оболонок, оболонка відкриває файл з O_TRUNC на стандартний висновок, а потім запускає додаток , яке не робить нічого виводити, то файл закривається і зліва усічений.

Однак у цьому випадку або при використанні truncateсистемного виклику, якщо процес, що заповнює цей файл, не відкрив його прапором O_APPEND, наступного разу, коли він запише в дескриптор файлу, він відкриється у файлі, він запише дані при зміщенні були у файлі.

Оскільки HFS + не підтримує розріджені файли, це означає, що простір до цього зміщення доведеться перерозподіляти та заповнювати нулями системою.

Отже, вам потрібно вбити програму, яка пише в цей файл, перш ніж обрізати його. Або вам потрібно переконатися, що програма відкриває файл O_APPEND(наприклад, >>якщо використовується перенаправлення оболонки).

Якщо ви хочете експериментувати з ним:

$ exec 3> x
$ yes | head -n 50000 >&3
$ ls -ls x
200 -rw-r--r--  1 me me  100000 Dec 16 21:32 x

Тепер fd 3 моєї оболонки - 100000 байт у файлі

$ : > x
$ ls -ls x
0 -rw-r--r--  1 me me  0 Dec 16 21:34 x

Тепер файл усічений (розмір 0, на диску не використовується простір).

$ echo >&3
$ ls -ls x
200 -rw-r--r--  1 me me  100001 Dec 16 21:34 x

Записавши 1 байт у файл зі зміщенням 100000, файл тепер має 100001 байт, перші - всі нулі, використовували б більше 100k на HFS +, але приблизно в одному блоці диска в більшості інших файлових систем Unix

З іншого боку, з:

$ exec 3>> x
$ yes | head -n 50000 >&3
$ ls -ls x
200 -rw-r--r--  1 me me  100000 Dec 16 21:35 x
$ : > x
$ echo >&3
$ ls -ls x
8 -rw-r--r--  1 me me  1 Dec 16 21:36 x

Запис 1 байт у файл не зі зміщенням 100000, а в кінці файлу через O_APPEND. Файл розміром у 1 байт і займає простір, необхідний для вміщення цього байта.