ofstream - определить, был ли файл удален между открытием и закрытием

Я читаю журнал на linux.
регистратор открыть файл по init.
и напишите в этот файл дескриптор при запуске программы.
если файл журнала будет удален после создания дескриптора файла,
не будет обнаружено никаких исключений/ошибок.
я попробовал:ofstream - определить, был ли файл удален между открытием и закрытием

out.fail() 
!out.is_open()

у меня есть Google это и найти этот пост.
http://www.daniweb.com/forums/thread23244.html

, так что теперь я понимаю, что даже если файл был удален с помощью rm. он по-прежнему существует, он просто несвязался.
Каков наилучший способ для этого?
1. это приложение журнала, поэтому производительность - это проблема, я не хочу использовать stat() для каждой записи.
2. Мне все равно, если какая-либо строка в файлах журнала будет отсутствовать в начало
3. пользователю разрешено удалять файл журнала, чтобы начать новый. Регистратор должен снова открыть файл.

источник

2010-02-04 jojo

Какую функцию вы используете для записи в файл? . для fwrite вы можете проверить результат возврата. И если размер отличается от ожидаемого, то повторно открыть (создать) файл .. –

@ Dyatlov тест результат не поможет, потому что файл существует, он просто отсоединен, запись выполнена.так и проверка файлов, спасибо – jojo

Я столкнулся с этим, исследуя ту же проблему, за исключением того, что процесс, выполняющий удаление, был logrotate - мой случай намного чище для исправления - logrotate имеет опцию - copytruncate - который будет разрешите эту проблему с протоколированием, не удалив файл вообще. –

Файлы являются "unlinked 'by rm.

Файл может иметь много имен. Если у него нет имен, и никто не откроет его, он будет восстановлен файловой системой и пространство, которое он занимает, может быть повторно использовано.

У Linux есть API для просмотра файлов под названием inotify, но это вызывает сложности и условия гонки.

Итак, вопрос большой, кто еще удаляет этот файл, когда он запущен, и почему? Не убеждайте их!

источник

2010-02-04 10:35:34 Will

наша система позволяет пользователю удалять файлы журналов, чтобы он мог начать работать, вот как работает наша система, и я не могу это изменить :( – jojo

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

inotify, вероятно, лучший способ решить эту проблему, даже если это сложно. –

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

Традиционный механизм UNIX для этого заключается в том, чтобы ваша программа устанавливала обработчик сигналов (часто для SIGHUP, поскольку в противном случае это не имеет смысла для демона). Обработчик сигналов содержит код, который заставляет программу закрывать и снова открывать файл журнала.

Затем пользователю сообщается, что после удаления файла журнала им необходимо отправить SIGHUP в программу.

источник

2010-02-04 11:43:02 caf

Единственный разумный способ справиться с этим - попытаться записать в журнал. Если сбой записи (в большинстве случаев это не будет), вам нужно выяснить, почему. В этот момент вы можете делать такие вещи, как использование stat, чтобы узнать, все ли в нем находится журнал - если это так, у вас есть какая-то ошибка на диске или ошибка разрешения, которую может быть сложно или невозможно восстановить, если это не так, повторно открыть и повторить попытку записи.

источник

2010-02-04 12:18:25

@Neil rm не реально удаляет файл, который он просто отсоединяет. файл все еще существует и используется приложением, запись будет успешной. , поэтому проверка на ошибку не поможет – jojo

ofstream - определить, был ли файл удален между открытием и закрытием

ответ

Смежные вопросы