Java: убедитесь, что Files.list () возвращает только «полные» файлы - PullRequest
Новая
       17

Java: убедитесь, что Files.list () возвращает только «полные» файлы

0 голосов
/ 21 ноября 2018

В моем приложении я наблюдаю каталог для новых файлов.

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

Хотя я сам никогда не сталкивался с проблемой, сотрудник сказал мне, что программное обеспечение предшественника провело дополнительную проверку того, что файл старше 3 секунд (рассчитывается с помощью (Files.getLastModifiedTime(path) - System.currentTimeMillis()) > 3000), потому что были неполные проблемыпереданные (или еще лучше: еще не полностью переданные) файлы были обработаны.

Могу ли я предположить, что файлы, возвращенные Files.list(), были полностью скопированы в каталог, который я наблюдаю?

Есть ли более чистый способ проверить, завершен ли файл?Проверка на 3 секунды больше похожа на хак, файл с размером в несколько ГБ может быть скопирован по медленному соединению (сети) и может быть не полностью передан даже после 3-х секунд.

1 Ответ

0 голосов
/ 21 ноября 2018

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

Я использую следующий метод, чтобы проверить, готов ли файл (в нем используется Java 1.8) 

public static boolean isFileReady(Path file) {
  try(FileChannel ch = FileChannel.open(file, StandardOpenOption.WRITE, StandardOpenOpption.APPEND); FileLock lock = ch.tryLock()) {
    if (lock == null) return false;
    return true;
  } catch (IOException ex) {
    return false;
  }
}

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

...