Does FindFirstFile/FindNextFile API pair cache results returned?

1
votes

I'm not sure if this was asked already, I can't seem to find it.

When I'm doing a folder contents enumeration, you know the usual:

FindFirstFile();
do
{
}while(FindNextFile());

What happens if while I'm still in my do/while loop the contents of the folder change? Say, a new file or a folder is added, altered or removed. Is that reflected in the results returned by FindNextFile?

1
c++windowswinapi
While I don't know the answer, it would be easy to find out by adding a Sleep statement for enough seconds in the loop so you can delete a file while the loop is in progress and see for yourself. – Amnon
The question seems moot, since you always have a TOCTOU race condition. This is spelled out explicitly for FindFirstFile: "Be aware that some other thread or process could create or delete a file with this name between the time you query for the result and the time you act on the information." – IInspectable
@IInspectable: OK, good point. So the answer is, no. The results are fetched "live." So, the reason I'm asking is because I'm writing a method to move contents of a folder, so in this case if I start moving files (or deleting them from a folder) it may affect the results returned by FindNextFile, right? – c00000fd
I would run through and pick up the files into a list of some sort, then process all the files when you have completed that process. If you do that one directory at a time (starting at the deepest level), you can always run a second scan to check for new files after you've done the copy/delete operation [which could of course take quite some time]. – Mats Petersson
You might or might not see any particular change that occurs during the loop. You'll need to cope with both scenarios. – Harry Johnston

1 Answers

4
votes

A quick test case shows that FindFirstFile does not cache the results on a local filesystem running on Windows 7. But as soon as FindNext is called, the results are cached (not fully, only a little bit). But since this is not documented in the Windows SDK, it must be seen as an implementation detail, which could change at any time. So write your code in a way that it does not depend on this behavior.