什么时候可以检查文件是否存在？

文件系统是不稳定的.这意味着您不能相信一个操作的结果仍然对下一个操作有效,即使它是下一行代码.你不能只说if (some file exists and I have permissions for it) open the file,你不能说if (some file does not exist) create the file.您的if条件结果总是可能会在代码的两个部分之间发生变化.操作是截然不同的:不是原子的.

更糟糕的是,问题的本质意味着如果你想要进行这种检查,你可能已经担心或意识到你无法控制的东西很可能发生在文件上.开发环境的本质使得此事件在测试期间不太可能发生,并且很难再现.因此,您不仅会遇到错误,而且在测试时也不会显示错误.

因此,在正常情况下,最好的做法是甚至不尝试检查文件或目录是否存在.相反,将您的开发时间用于处理文件系统中的异常.无论如何,您必须处理这些异常,这样可以更好地利用您的资源.即使异常很慢,检查文件是否需要额外的磁盘访问,磁盘访问速度要慢得多.在另一个问题中,我甚至对这个效果有一个很好的答案.

但我有些疑惑.例如,在.Net中,如果确实总是如此,那么这些.Exists()方法首先不会出现在API中.还要考虑您希望程序需要创建文件的方案.想到的第一个例子是桌面应用程序.此应用程序将默认用户配置文件安装到其主目录,并且每个用户第一次启动应用程序时,它会将此文件复制到该用户的应用程序数据文件夹.它希望该文件在第一次启动时不存在.

那么什么时候可以提前检查文件的存在(或其他属性,如大小和权限)？是否期望在第一次尝试时失败而不是成功足够的经验法则？

File.Exists方法主要用于在您不打算打开文件时测试文件是否存在.例如,测试是否存在一个锁定文件,它的存在会告诉你一些东西,但其内容并不重要.

如果要打开该文件,则无论先前调用File.Exists的结果如何,都需要处理任何异常.因此,一般来说,在这些情况下调用它没有实际价值.只需在open方法中使用适当的FileMode枚举值并处理任何异常,就这么简单.

编辑:尽管这是基于.Net API,但它基于底层系统API.Windows和Unix都有系统调用(即CreateFile),它们使用等效的FileMode枚举.事实上,在.Net(或Mono)中,FileMode值只是传递给底层系统调用.

作为一般政策,类似File.Exists或类似的方法WeakReference.Alive或SomeConcurrentQueue.Count作为确保"好"状态存在的手段无用,但作为确定"坏"状态存在而不做任何不必要的手段(和可能适得其反的工作.在涉及锁(和文件,因为它们通常包括锁)的许多场景中可能出现这种情况.因为所有需要锁定一组资源的例程应该在任何可行的情况下始终以一致的顺序获取对这些资源的锁定,所以可能需要在获取资源之前获取预期存在的一个资源上的锁定.或者可能不存在.在这种情况下,虽然不可能避免可能锁定第一个资源的可能性,但是无法获取第二个资源,然后释放第一个锁而没有对其进行任何有用的工作,在之前检查第二个资源是否存在获得第一个锁定将最大限度地减少不必要的和无用的努力.