7

Say you have a running process writing to a file, over an amount of time. In the explorer process, highlighting that file will show the "current size". Subsequent F5 keypresses will update the current size of that file, but surprisingly, it takes two key presses to view the most correct size. Pressing the F5 key once will only get you a higher value.

This has been bothering me (mildly) for years, and I would like to know why!

It is reproducible in (at least) Windows 7, e.g. by downloading a large file.

Improve this question
4
  • How do you know/are verifying the process is done writing to the file when you press F5 the first time? If the application has a GUI, it's display may not strictly correlate with whatever thread or possibly other process is actually writing to the file.
    – LawrenceC
    Dec 2, 2014 at 15:32
  • This occurs only while the write process is going on, not after it is done. I do presume the application (or the OS) flushes bytes periodically (and linearly in time) to the file. It's the discrepancy between the two keypresses that bothers me.
    – Henning Klevjer
    Dec 2, 2014 at 15:37
  • @HenningKlevjer Sorry, you were totally right. I now wrote some programs to test it, debugged with SysInternals ProcMon and googled the reason. Thanks for that very good question!
    – Werner Henze
    Dec 2, 2014 at 17:44
  • Disk caching would be my guess.
    – Ƭᴇcʜιᴇ007
    Dec 2, 2014 at 17:57

1 Answer 1

Reset to default
9

There is an MSDN blog describing why Windows behaves as you describe it.

First let's mention that what you see is only on NTFS.

To test what you said I wrote a small program that writes 40 kB to a file every 5 seconds. The file is kept open between every write. A second program uses FindFirstFileEx to get the current file size. As third I use dir in cmd.exe. With this setup I can exactly see what you describe.

The cause of this issue is a design decision taken in NTFS. In NTFS (as in Unix filesystem) the same file can be in two directories - this is called a hardlink. This means you have two directories, each having an entry for the file and you have the file itself with it's properties. File size is a property that belongs to the file, so it is stored there. But, if someone wants a list of the files in a directory with properties like file size, then you would have very low performance if you had not only to read the directory itself but also read information from every file. Data for one directory is likely to be stored sequentially, but data for different files is likely to be scattered all over the disc. Therefore NTFS stores a copy of the file size in the directory entry/entries.

You might have guessed it, this also has a performance hit. Think about 10 hardlinks to the same file. Do you want NTFS to update 10 directory entries every time you write to a file? No. So a second design decision was made since Vista: data in the directory entry is only updated when the file is closed.

You can easily check that: run a program that writes to a file and keeps the file open. Run dir and you will not see an updated size. Or write a file with Notepad (which closes the file at the end) and immediately the new file size is displayed in dir or Explorer.

How come that F5 helps refreshing the file size? Explorer calls GetNamedSecurityInfo which internally opens the file and closes it (you can check that in SysInternals Process Monitor). If I call GetNamedSecurityInfo in my own program and then call FindFirstFileEx I see the new file size immediately. So the observed behavior is exactly as expected from theory.

But why don't you see the new file size immediately in Explorer? It seems that Explorer is first calling FindFirstFileEx and then GetNamedSecurityInfo. So Explorer is getting the old size and then triggers updating the directory entry. If you run dir in cmd.exe you can see that the directory entry now has the new file size. It is only that Explorer does not yet know it. It takes Explorer a second F5 to get the latest size and then again trigger an update.

From an application developers view I would not consider this an Explorer bug - this is a special case for one of the supported file systems, and an application should abstract from the file systems. But as Explorer is part of Windows I tend to think that Microsoft could have done better and changed the order of the function calls to get a better user experience.

BTW, thanks for that very interesting question! I like having learned such NTFS interna.

Improve this answer
3
  • This is not what I'm seeing. While the writing process has the file open, Explorer requires two keypresses. As a concrete example: I'm downloading a 1 GB file over a couple of minutes. A minute in, the file size is 100 MB. When I wait another minute, and press F5 once, the file size may be 102 MB, but if I press the F5 key a second time just after, it may be 200 MB (which I guess is the correct value, rather than the 102 I was just presented with).
    – Henning Klevjer
    Dec 2, 2014 at 15:46
  • 1
    @HenningKlevjer That makes perfect sense. The first keypress updates the size (on the close). The second keypress reads the updated size.
    – David Schwartz
    Dec 2, 2014 at 18:19
  • Thank you so much for the explanation. This has been bugging me for years.
    – Dawn Benton
    Dec 10, 2014 at 2:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .