The ‘Directory.GetLastWriteTime()‘ method return the same date/time although a file inside directory is changed

Question

I'm observed a strange problem when using the File.GetLastWriteTime() method to get the last write date and time of the specified directory.

Consider the following code:

// ‘path’ is directory for which need to obtain modification date/time information.
DateTime dtp = File.GetLastWriteTime(path);
DateTime dtf = File.GetLastWriteTime(path+@"\log.txt");

Console.WriteLine($"{path}, dir: {dtp:hh:mm:ss.fff}, file: {dtf:hh:mm:ss.fff}");

Now, when I update the log.txt file, for example, by performing

echo some-text >> "log.txt"

from the command prompt the dtf is updated but the dtp doesn't changed.

The specified directory date and time is changed only if I create a new file or delete some file inside the directory.

Can anyone help me to understand what I missed here?

---

NOTES:

1. The same happens when using the Directory.GetLastWriteTime() method.

2. Used the Windows 10.

3. The OS doesn't have any registry fixes applied like described in this post: File.GetLastWriteTime seems to be returning 'out of date' value

Answer 1

An explanation that I found in doc is that:

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

I think is challenging because a file or a directory may in fact be a virtual one or can be a symlink (in Linux).

Answer 2

The LastAccessTime mentioned in some comment is unrelated to LastWriteTime.

With LastAccessTime there are no guarantees as to whether it is implemented, how often it gets updated, and how accurate it is.

However, with LastWriteTime there are plenty of guarantees, at least on a local NTFS file-system; if it did not work correctly, then lots of other things would not work, including one that we are already quite familiar with: Building. (Recompiling only those source files that have changed since the last build, which only happened a few seconds ago.)

What is happening here is that windows (or NTFS to be more precise) delays the updating of LastWriteTime of a file until that file is closed. So, LastWriteTime may be inaccurate for as long as you are keeping the file open, but once you close that file, it will be updated.

Essentially, you can think of LastWriteTime as LastCloseTime, or more precisely, LastCloseTimeAfterOpenedForWriting.

In the question you say that you update your log.txt file by performing, for example:

echo some-text >> "log.txt"

Conceptually, this opens "log.txt" for appending, writes some-text to it, and then closes it. But I said conceptually. If that was in fact happening, then your LastWriteTime would be updating correctly, but it doesn't.

What is possibly happening here is that the command processor is applying some optimization where log.txt is being kept open across multiple invocations of the >> operator. I do not know this for sure, I am just postulating it.

I do not know exactly what you are doing and how you are doing it, but the solution to your problem is likely to involve somehow making sure that your file has been closed before trying to query its LastWriteTime.

Maybe try doing all of your appending to the file via a nested instance of the command processor? Be advised though, that the command processor might also have optimizations for that, too, so if it does not work, you might have to keep trying other possible solutions.