Я считаю, что это Java ошибка / функция. Если вы выполняете поиск в базе данных Java Bugs , появляется ряд сообщений об ошибках, касающихся несовместимого поведения canWrite()
и canRead()
в Windows системах.
Основы c проблема в том, что когда Microsoft добавила поддержку файловых систем NTFS в библиотеку Win32, они не стали «учить» вызовы проверки доступа для понимания NTFS ACLS. Вместо этого старые вызовы по-прежнему сообщают о возможности чтения / записи, основываясь исключительно на разрешениях MSDOS. Были добавлены новые методы API для обработки проверки доступа к файловой системе NTFS, но для их использования необходимо изменить код приложения (в данном случае JVM).
Судя по сообщениям об ошибках Java, реакция Команда Sun Java, когда они обнаружили, что эта ошибка была нарушена Java в WindowsNT, должна была (правильно) сказать, что «это ошибка Windows». Но Microsoft не исправила это. И инженерам Sun было уже слишком поздно применять обходной путь к собственной реализации Java. Конечным результатом является то, что File.canRead()
и File.canWrite()
могут давать неверные результаты на Windows при некоторых обстоятельствах.
Связанные Java ошибки были помечены как WontFix.
Так в чем же решение?
Одним из решений является использование Files.isReadable()
и Files.isWritable()
. Насколько я понимаю, одной из (многих) вещей, которые они исправили в Files
, было аномальное поведение методов File.canRead()
и File.canWrite()
.
Однако я не советую проверять, файлы существуют, доступны для чтения или записи. Просто попытайтесь выполнить файловую операцию и разобраться с исключениями. Это имеет следующие преимущества:
Это позволяет избежать необходимости устранения несоответствий в управлении доступом. (Например, существуют несоответствия в Linux при использовании SE- Linux. Доступ к файлу может быть заблокирован SE- Linux, несмотря на то, что это разрешено битами разрешения доступа к файлу и списками ACL.)
Это позволяет избежать условий гонки, когда что-то еще (другой поток или другая программа) изменяет разрешения файловой системы в неподходящее время.
Также рекомендуется переключиться на используя более новые java.nio.*.*
API, а не старый File
класс. Более новые API дают лучшую диагностику.