2009-04-28 7 views

ответ

7

Удаление файла в UNIX делает две вещи:

  • удаляет запись каталога для него.
  • Если процессы не открыты, и никакие другие записи в каталоге не указывают на него (жесткие ссылки), он освобождает пространство.

Ваш nohupped процесс с радостью продолжит писать в файл, который раньше назывался nohup.out, но теперь известен как ничто иное, как дескриптор файла в этом процессе.

Вы даже можете создать другой процесс nohup.out, он не будет мешать первому.

Когда все жесткие ссылки исчезли, и все процессы закрыли его, дисковое пространство будет восстановлено.

+0

Если можно изменить местоположение inode на/dev/null , Я предполагаю, что можно изменить его на другие места. Предположим, я хочу, чтобы stdout из команды find в другое место каждые 5 секунд. Я знаю, что я мог бы создать новую жесткую ссылку на каждом шаге, удалив всегда последнюю ссылку. Однако я не могу понять этот процесс. Как вы можете гарантировать, что каждые 5 секундные выходы имеют отдельный номер inode? Как вы можете обеспечить асинхронный процесс, чтобы вы, безусловно, записывали все? –

+0

Это первое предложение сбивает с толку, @SQ, я не думаю, что вы понимаете, что такое inode - это действительно просто идентификатор для базового файла (данные, а не запись в каталоге). Изменяя на/dev/null, вы имеете в виду «find />/dev/null»? найти просто выходы в дескриптор файла, который он наследует от оболочки. Используя перенаправление, оболочка присоединяет stdout к файлу (или драйверу устройства, например/dev/null), а затем fork/execs find, который будет использовать этот дескриптор stdout. найти себя не знает, к какому файлу он пишет, просто описатель. Поэтому он не будет воссоздавать запись в каталоге, так как файл все еще существует. – paxdiablo

+3

@SimpleQuestions: очень мало программ открывают файл каждый раз, когда они пишут, особенно если они не записывают стандартный вывод. Они просто продолжают использовать открытый файловый дескриптор. Как только ваша программа начнет записываться в данный файл, она продолжает это делать. Вы не можете изменить файл, на который он пишет, путем (пере) перемещения файла. –

2

Это стандартное поведение в Unix.

Когда вы удалили файл, последняя ссылка в файловой системе была удалена, но файл все еще был открыт, и поэтому вывод find (в данном случае) был записан на блоки диска в пуле буфера ядра и, возможно, даже на диск. Но у файла не было имени. Когда find вышел, ни один процесс или файл (inode) не ссылался на файл, поэтому пространство было выпущено. Это один из способов, когда временные файлы, которые исчезают при выходе из программы, создаются - открывая файл, а затем удаляя его. (Это предполагает, что вам не нужно имя для файла, ясно, если вам нужно имя для временного, эта техника не будет работать.)

+0

+1 хороший практический пример о временных файлах –

+0

Поскольку команда rm удаляет последнюю ссылку, данные все еще находятся на диске, если только она не перезаписывается. Какова вероятность найти данные, не зная его последнего соединения? –

+0

Вероятность nil - если вы не засунули сырое устройство. Файл использует пробел (df будет сообщать об этом как «в использовании»). Однако нет имени, с помощью которого вы можете получить к нему доступ. Первоначальный процесс мог теоретически читать данные (а также записывать их); конечно, 'find' не сделает этого. –