Файл Java File.delete() иногда оставляет недоступные файлы (Windows)

Question

Я пытаюсь программно очистить файлы журналов из запущенной (!) Системы, состоящей из нескольких серверов Java и не-Java. Я использовал функцию File.delete() Java и обычно работает нормально. Я также прекрасно разбираюсь в том, что файлы журнала, которые в настоящее время используются, не удаляются, поэтому я просто регистрирую его как предупреждение, когда File.delete() возвращает false.

Однако в файлах журналов, которые в настоящее время все еще записываются приложениями NON-Java (Postgres, Apache HTTPD и т. Д., Приложения Java также могут быть затронуты, но я еще не заметил, и все они используют то же самое (в любом случае, это похоже на ОК) на самом деле не удалены (это то, что я ожидал), однако File.delete() возвращает «true» для них. Но эти файлы не только сохраняются в файловой системе (Windows explorer и «dir» все еще показывают их), но потом они недоступны ... когда я пытаюсь открыть их с помощью текстового редактора и т. Д. Я получаю «доступ запрещен» »или аналогичные сообщения об ошибках, когда я пытаюсь скопировать их с помощью explorer, он также утверждает, что у меня нет разрешений, когда я проверяю его« свойства »с помощью explorer, он дает мне« У вас нет разрешения на просмотр или редактирование этого объекта разрешения».

Просто, чтобы быть ясным: до того, как я запустил операцию File.delete(), я мог без проблем получить или удалить эти файлы, операция удаления «разрывает» их. Как только я остановлю приложение, файл исчезнет, ​​и при перезапуске приложение создаст его с нуля, и все вернется к норме. Проблема заключается в том, что при повторном запуске приложения после операции очистки файла журнала приложение регистрируется в нирване.

Это поведение немного напоминает поведение файлов Linux: если вы удаляете файл, который все еще остается открытым приложением, он исчезает из файловой системы, но приложение, все еще содержащее дескриптор файла, будет счастливо продолжайте писать в этот файл, но после этого вы никогда не сможете получить к нему доступ. Единственное различие заключается в том, что здесь файлы все еще видны в FS, но также недоступны в противном случае.

Следует отметить, что как моя программа Java, так и сами приложения работают с пользователем системы.

Я также пробовал Files.delete(), который, как утверждается, генерирует IOException, указывающий на ошибку ... но кажется, что ошибок нет.

Что я пытался решить проблему, это проверить, заблокированы ли файлы в данный момент, используя метод, описанный здесь https://stackoverflow.com/a/1390669/5837050, но это работает только для некоторых файлов, а не для всех.

Мне в основном нужен надежный способ (по крайней мере для Windows, если он работал и для Linux, это было бы замечательно), чтобы определить, используется ли какой-либо файл какой-либо программой, поэтому я просто не мог его удалить.

Любые намеки приветствуются.

Answer 1

Я не воспроизвел его, но это похоже на ожидаемое поведение ОС, обычно разные приложения работают с разными пользователями, которые имеют право собственности на этот тип файлов, но я понимаю, что вы хотите, как мастер-очистка Java, которая проверяет файлы журнала не используются, чтобы удалить их (бегая с достаточным количеством грантов, конечно).

Итак, учитывая, что поведение ОС не изменится, я бы предложил настроить ваши журналы с помощью политик «roll file appender», а затем проверить файлы, соответствующие этим политикам.

Проверьте политику отката для Logback, чтобы сделать вам идею: http://logback.qos.ch/manual/appenders.html#onRollingPolicies

Например, если ваша политика Appender файл «более чем один день или больше, чем 1Gb», а затем просто удалить файлы, дата последнего издания являются старше одного дня или размером 1 ГБ. С помощью этого правила вы обязательно удалите файлы журнала, которые не используются.

Обратите внимание, что .. с правильной политикой прокатки может быть, вы даже не нужен ваш метод продувки, посмотрите на этом примере конфигурации:

<!-- keep 30 days' worth of history capped at 3GB total size --> 
    <maxHistory>30</maxHistory> 
    <totalSizeCap>3GB</totalSizeCap> 

Я надеюсь, что это может помочь вам немного !!