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?
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.
No they are not in the context you are using.
From FileSystemInfo.LastWrite -> MSDN
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.
no problem see msdn:
http://msdn.microsoft.com/en-us/library/system.io.fileinfo.aspx
Thread Safety Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
and notice:
When the properties are first retrieved, FileInfo calls the Refresh method and caches information about the file. On subsequent calls, you must call Refresh to get the latest copy of the information.