Is it safe to create a FileInfo on a file that is currently being written to?

Question

In my application (C# 4.5 winforms app) I periodically check the contents of a folder and store the details of any files found into a database. Within this routine, I create a FileInfo instance using new FileInfo(path), and I read the properties CreationTime, LastWriteTime, LastAccessTime, Length and Attributes. I never call any methods on the FileInfo instance.

What I want to know: is there any risk of corruption, locking or runtime errors if a file is currently being written to by a third party application (or in the process of being copied to the folder by Windows) whilst I create the FileInfo object or access it's properties?

Answer 1

Yes, this is "safe". This is dealt with at a very low level, the file system driver. A file on common file systems like FAT or NTFS has two distinct structures on disk. First is the directory entry, it stores metadata about the file. Like the name, timestamps, attributes and length. The actual file data is stored elsewhere, a chain of clusters that stores the file data.

FileInfo exclusively gives you the metadata for a file. The file data is much more sensitive, highly subject to change as a process writes to the file. Notable is that you can lock access to the file data with the FileShare options. But there's no way to lock the metadata. Accordingly you can always get the FileInfo for a file, regardless what another process is doing with the file.

Of course, the actual FileInfo properties are subject to change while a process writes to the file. They are updated lazily, particularly the LastAccessTime property. If you want to be sure that you've got accurate info that cannot change then you need to obtain a lock on the file. Do so by opening the file with FileShare.Read or FileShare.None. Which ensures that no other process can open the file for writing, as long as you have the file opened. Do note that that can easily throw an IOException, you'll only gain the lock when no other process came before you and opened the file for writing.

Answer 2

No they are not in the context you are using.

From FileSystemInfo.LastWrite -> MSDN

Note This method may return an inaccurate value, because it uses native functions whose values may not be continuously updated by the operating system.

But Imagine for a second, they were returning latest values. If you have consumed the value (dependent upon time), and files are overwritten after that, your last accessed values would become wrong/corrupted. So this does not make sense.