什么时候可以检查一个文件是否存在？ [英] When is it okay to check if a file exists?
问题描述
如果（有些文件存在，我有权限）打开文件，你不能说 if（some文件不存在）创建文件。在你的代码的两部分之间总是有可能你的 if 条件的结果会改变。这些操作是不同的：不是原子的。更糟糕的是，问题的本质意味着如果你想做这个检查，已经担心或意识到你不能控制的事情可能发生在文件中。开发环境的本质使得这个事件在测试过程中不太可能发生，而且很难重现。所以不仅你有一个bug，但是这个bug在测试时不会显示出来。因此，在正常情况下，最好的做法是甚至不尝试检查文件或目录是否存在。相反，把你的开发时间放在处理文件系统的异常。无论如何，你必须处理这些异常，所以这是一个更好地利用你的资源。即使异常缓慢，检查文件的存在也需要额外的磁盘访问，并且磁盘访问速度比较慢。我甚至有一个良好的投票回答在另一个问题的这种影响。
但我有些怀疑。在.Net中，例如，如果这真的是总是，那么 .Exists（）方法将不在API中。还要考虑您希望您的程序需要创建文件的情况。想到的第一个例子是桌面应用程序。此应用程序将一个默认的用户配置文件安装到它的主目录，并且每个用户第一次启动应用程序时，它将该文件复制到该用户的应用程序数据文件夹中。它期望该文件在第一次启动时不存在。
那么，何时可以提前检查文件的存在（或其他属性，如大小和权限）？预期失败，而不是成功的第一次尝试一个足够好的经验法则？
如果打算打开文件，那么无论先前调用File.Exists的结果如何，您都需要处理任何异常。所以，一般来说，在这种情况下调用它是没有实际价值的。只需在open方法中使用适当的FileMode枚举值并处理任何异常就可以了。
$ b 编辑：即使这是在.Net API它基于底层的系统API。 Windows和Unix都有系统调用（即CreateFile），它们使用FileMode枚举的等价物。事实上，在.Net（或Mono）中，FileMode的值只是传递给底层的系统调用。
File systems are volatile. This means that you can't trust the result of one operation to still be valid for the next one, even if it's the next line of code. You can't just say if (some file exists and I have permissions for it) open the file, and you can't say if (some file does not exist) create the file. There is always the possibility that the result of your if condition will change in between the two parts of your code. The operations are distinct: not atomic.
To make matters worse, the nature of the problem means that if you're tempted to make this check, odds are you're already worried or aware that something you don't control is likely to happen to the file. The nature of development environments make this event less likely to happen during your testing and very difficult to reproduce. So not only do you have a bug, but the bug won't show up while testing.
Therefore under normal circumstances the best course of action is to not even try to check if a file or directory exists. Instead, put your development time into handling exceptions from the file system. You have to handle these exceptions anyway, so this is a much better use of your resources. Even though exceptions are slow, checking the existence of a file requires an extra trip to disk, and disk access is much slower. I even have a well-voted answer to this effect in another question.
But I'm having some doubts. In .Net, for example, if that's really always true, the .Exists() methods wouldn't be in the API in the first place. Also consider scenarios where you expect your program to need to the create file. The first example that comes to mind is for a desktop application. This application installs a default user-config file to it's home directory, and the first time each user starts the application it copies this file to that user's application data folder. It expects the file not to exist on that first startup.
So when is it acceptable to check in advance for the existence (or other attributes, like size and permissions) of a file? Is expecting failure rather than success on the first attempt a good enough rule of thumb?
The File.Exists method exists primarily for testing for the existence of a file when you do not intend to open the file. For example testing for the existence of a locking file whose very existence tells you something but whose contents are immaterial.
If you are going to open the file then you will need to handle any exception regardless of the results of any prior calls to File.Exists. So, in general, there is no real value in calling it in these circumstances. Just use the appropriate FileMode enumeration value in your open method and handle any exceptions, as simple as that.
EDIT: Even though this is couched in terms of the .Net API, it is based on the underlying system API. Both Windows and Unix have system calls (i.e. CreateFile) that use the equivalent of the FileMode enumeration. In fact in .Net (or Mono) the FileMode value is just passed through to the underlying system call.
这篇关于什么时候可以检查一个文件是否存在？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
