File.exists() 为实际存在的文件（目录）返回 false

Question

TLDR：File.exists() 有问题，我想了解原因！

---

我在我的 Android 应用程序中遇到了一个奇怪的问题（经常发生）。我会尽量简短。

首先，我将向您展示代码，然后提供一些附加信息。这不是完整的代码。只是问题的核心。

示例代码：

String myPath = "/storage/emulated/0/Documents";
File directory= new File(myPath);
if (!directory.exists() && !directory.mkdirs()) {
   throw new IllegalArgumentException("Could not create the specified directory: " + directory.getAbsolutePath() + ".");
}

大多数时候这工作正常。 几次但是抛出异常，这意味着目录不存在并且无法创建。在每 100 次运行中，它可以正常运行 95-96 次，失败 4-5 次。

• 我已经在我的清单中声明了存储/读取外部存储/写入外部存储的权限并在运行时请求了权限。问题不在于那里。 （如果有什么我在这一点上有太多的权限：D）。毕竟，如果是权限问题，它每次都会失败，但在我的情况下，失败率是 4% 或 5%。
• 使用上面的代码，我试图创建一个指向“文档”文件夹的文件。在我的应用程序中，我实际上使用的是String myPath = Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_DOCUMENTS).getPath();
  在发生错误的特定设备中，此路径恰好是“/storage/emulated/0/Documents”，这就是我在给你的示例代码中硬编码它的原因。
• 如果我在设备上使用文件资源管理器应用程序（即“Astro 文件管理器”，我可以看到该文件夹​​确实存在并且有一些内容，并且还确认路径真的 是“/storage/emulated/0/Documents”。
• 这在我本地从未发生过。只有应用程序的用户会遇到此问题，并且由于 Firebase/Crashlytics，我知道问题的存在。用户拥有与我用于开发的完全相同的平板电脑，即联想 TB-8504X。 （我在一家公司工作，我们提供软件和硬件）。

那么，您对为什么会出现这个问题有任何想法吗？

有没有人经历过类似的事情？

“文档”文件夹的路径是否有时会是“/storage/emulated/0/Documents”，有时会变成在同一物理设备上的其他路径吗？

我是一位经验丰富的 Android 开发人员，但我在 Android 架构和 Android 文件系统方面相当新手。可能是在启动时（当设备通电或重新启动后）文件系统在我的代码检查目录是否存在时尚未“安装”“磁盘”？在这里，我尽可能松散地使用术语“安装”和“磁盘”。此外，我的应用程序实际上是一个启动器/家长控制应用程序，因此它是设备启动时首先触发的东西。我几乎确信这根本没有意义，但在这一点上，我正试图看到更大的图景并探索超越典型 Android 开发的解决方案。

非常感谢您的帮助，因为这个问题开始让我感到不安。

期待任何有用的回复。

提前致谢。

编辑（2019 年 8 月 27 日）：

我遇到了这个Java Bug Report，虽然它已经过时了。据此，在 NFS 挂载的卷上操作时，java.io.File.exists 最终会执行stat(2)。如果stat 失败（它可能由于多种原因而失败），那么File.exists（错误地）假定stat'ed 的文件不存在。难道这就是我烦恼的根源吗？

编辑（2019 年 8 月 28 日）：

今天我可以为这个问题添加一个赏金，试图引起更多的关注。我会鼓励您仔细阅读问题，查看 cmets 忽略声称这与 Realm 的客户支持有关的问题。领域代码确实是使用不可靠方法的代码，但我想知道是该方法不可靠的原因。 Realm 是否可以解决此问题并改用其他代码，这超出了问题的范围。我只是想知道是否可以安全地使用File.exists()，如果不能，为什么？

再次，提前谢谢大家。获得答案对我来说非常重要，即使它过于技术性并且涉及对 NFS 文件系统、Java、Android、Linux 或其他任何东西的更深入了解！

编辑（2019 年 8 月 30 日）：

因为一些用户建议用其他方法替换File.exists()，我想说明我现在感兴趣的是低估了为什么该方法失败了而不是 可以改用什么作为解决方法。

即使我想用其他东西替换File.exists()，我也无法这样做，因为这段代码位于RealmConfiguration.java 文件中（阅读-only) 这是我在我的应用程序中使用的领域库的一部分。

为了让事情更清楚，我将提供两段代码。我在活动中使用的代码以及在 RealmConfiguration.java 中调用的方法因此：

我在活动中使用的代码：

File myfile = new File("/storage/emulated/0/Documents");
if(myFile.exists()){        //<---- Notice that myFile exists at this point.        
   Realm.init(this);

   config = new RealmConfiguration.Builder()
   .name(".TheDatabaseName")
   .directory(myFile)       //<---- Notice this line of code.
   .schemaVersion(7)
   .migration(new MyMigration())
   .build();

   Realm.setDefaultConfiguration(config);
   realm = Realm.getDefaultInstance();        
}

此时 myFile 存在，并且驻留在 RealmConfiguration.java 中的代码被调用。

RealmConfiguration.java 崩溃的方法：

    /**
         * Specifies the directory where the Realm file will be saved. The default value is {@code context.getFilesDir()}.
         * If the directory does not exist, it will be created.
         *
         * @param directory the directory to save the Realm file in. Directory must be writable.
         * @throws IllegalArgumentException if {@code directory} is null, not writable or a file.
         */
        public Builder directory(File directory) {
            //noinspection ConstantConditions
            if (directory == null) {
                throw new IllegalArgumentException("Non-null 'dir' required.");
            }
            if (directory.isFile()) {
                throw new IllegalArgumentException("'dir' is a file, not a directory: " + directory.getAbsolutePath() + ".");
            }
------>     if (!directory.exists() && !directory.mkdirs()) {   //<---- Here is the problem
                throw new IllegalArgumentException("Could not create the specified directory: " + directory.getAbsolutePath() + ".");
            }
            if (!directory.canWrite()) {
                throw new IllegalArgumentException("Realm directory is not writable: " + directory.getAbsolutePath() + ".");
            }
            this.directory = directory;
            return this;
        }

所以，myFile 存在于我的活动中，调用了 Realm 代码，突然 myFile 不再存在。我再次指出，这是不一致的。我注意到崩溃率为 4-5%，这意味着 myFile 大部分时间都存在于活动中以及领域代码对其进行检查时。

我希望这会有所帮助。

再次提前致谢！

Answer 1

首先，如果您使用的是 Android，Java Bugs 数据库中的错误报告是不相关的。 Android 不使用 Sun / Oracle 代码库。 Android 最初是对 Java 类库的无尘室重新实现。

因此，如果 Android 上的 File.exists() 中存在错误，错误将在 Android 代码库中，并且任何报告都将在 Android 问题跟踪器中。

但是当你这样说的时候：

据此，在 NFS 挂载的卷上运行时，java.io.File.exists 最终会执行 stat(2)。如果 stat 失败（它可能由于多种原因而失败），那么File.exists（错误地）假定正在统计的文件不存在。

1. 除非您使用的是 NFS，否则该错误报告不直接相关。
2. 这不是错误/错误。这是一个限制。
3. 在文件系统级别，Linux 支持多种不同类型的文件系统是不争的事实，与“普通”文件系统相比，它们中的许多以意想不到的方式运行。 JVM 不可能在 Java API 级别隐藏所有奇怪的文件系统特定的边缘情况。
4. 在 API 级别，File.exists无法报告任何错误。签名不允许它抛出IOException，并且抛出未经检查的异常将是一个破坏 更改。它只能说true 或false。
5. 如果您想区分false 的各种原因，您应该改用较新的Files.exists(Path, LinkOptions...) 方法。

这会是我烦恼的根源吗？

是的，它可以，而且不仅仅是在 NFS 案例中！见下文。 （对于Files.exist，NFS stat 故障很可能是EIO，这将引发IOException 而不是返回false。）

---

Android 代码库（android-4.2.2_r1 版本）中的File.java 代码为：

public boolean exists() {
    return doAccess(F_OK);
}

private boolean doAccess(int mode) {
    try {
        return Libcore.os.access(path, mode);
    } catch (ErrnoException errnoException) {
        return false;
    }
}

注意它如何将任何ErrnoException 转换为false。

更多挖掘表明 os.access 调用正在执行本机调用，该调用发出 access 系统调用，如果系统调用失败则抛出 ErrnoException。

所以现在我们需要查看访问系统调用的记录行为。 man 2 access 是这样说的：

1. F_OK 测试是否存在 文件。
2. 发生错误（模式中至少一位 请求被拒绝的权限，或者模式为 F_OK 并且文件 不存在，或者发生了其他错误），返回-1，并且 errno 设置得当。

3. 如果出现以下情况，access() 将失败：

   • EACCES 请求的文件访问将被拒绝，或者搜索 路径前缀中的目录之一的任务被拒绝 的路径名。 （另见 path_resolution(7)。）

   • ELOOP 解析路径名时遇到太多符号链接。

   • ENAMETOOLONG 路径名太长。

   • ENOENT 路径名的组件不存在或者是悬空符号 链接。

   • ENOTDIR 在路径名中用作目录的组件实际上不是 目录。

   • EROFS 已请求只读文件的写入权限 文件系统。

4. access() 可能会失败，如果：

   • EFAULT 路径名指向您可访问的地址空间之外。

   • EINVAL 模式指定不正确。

   • EIO 发生 I/O 错误。

   • ENOMEM 可用内核内存不足。

   • ETTXTBSY 已请求对正在执行的可执行文件进行写访问。

我已经删除了我认为在技术上不可能或不可信的错误，但仍然很少考虑。

---

另一种可能性是某些事情（例如您的应用程序的其他部分）正在删除或重命名文件或（假设的）符号链接，或更改文件权限......在你背后。

但我不认为File.exist() 坏了¹，或者主机操作系统坏了。这在理论上是可能的，但您需要一些明确的证据来支持该理论。

^{1 - 它没有被破坏，因为它的行为与方法的已知行为没有什么不同。你可能会争论直到奶牛们回家关于行为是否“正确”，但自 Java 1.0 以来一直如此，并且在 OpenJDK 或 Android 中无法更改它而不破坏过去 20 多个编写的数​​千个现有应用程序年。它不会发生。}

---

接下来要做什么？

我的建议是使用strace 来跟踪您的应用程序正在进行的系统调用，看看您是否可以得到一些线索，说明为什么某些access 系统调用会给您带来意想不到的结果；例如路径是什么，errno 是什么。见https://source.android.com/devices/tech/debug/strace。

Answer 2

我遇到过类似的问题，但故障率较高，其中防病毒软件锁定了FileSystem，因此（几乎立即）失败了任何请求

解决方法是改用java.nio.Files.exists()。