Итерация DirectoryStream и изменение содержимого каталога в одно и то же время

В документации DirectoryStream четко указано:

Итератор слабо согласован. Это поточно-безопасный, но не заморозить каталог во время итерации, чтобы он мог (или не иметь) отражать обновления в каталоге, которые происходят после того, как DirectoryStream создано.

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

Мой вопрос: при каких обстоятельствах итерация отражает обновления содержимого каталога? К сожалению, формальная документация очень смутно. По меньшей мере.

Ответ 1

Документация преднамеренно расплывчата. JVM должен работать на нескольких машинах разных типов: Windows и Unix-производных. Различные файловые системы имеют разные типы поведения. Вы должны (я повторяю, MUST) дизайн для худшего случая, если вы хотите, чтобы ваша программа надежно работала на нескольких компьютерах.

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

Ответ 2

Поскольку DirectoryStream является интерфейсом, и поскольку эта часть NIO.2 должна быть подключаемой, не ограничивайте свое рассмотрение реалиями, которые поставляются с JDK для Linux и Windows. Было бы вполне возможно написать собственную реализацию с таким же поведением или для кластерной или распределенной реализации, чтобы иметь такое поведение как побочный эффект.

Документация преднамеренно неопределенная, и в POSIX она передает readdir, которая также преднамеренно неопределенная:

Если файл удаляется из каталога или добавляется в каталог после последнего вызова opendir() или rewinddir(), то будет ли последующий вызов readdir_r() записи для этого файла не указан.

Однако, если вы после конкретного случая, когда реализация полагалась на эту неопределенность, тогда Linux ext3 readdir и параллельные обновления показывает случай, когда rsync, в файловой системе ext3 с большой громкостью, казалось, что файлы отображаются в каталоге вне порядка, в котором они были созданы.