🚀 go-pugleaf

Hi,

I have a situation in which I watch for and process files as they are
created in a certain folder.  I do this in a thread using
FindFirstChangeNotification (and FILE_NOTIFY_CHANGE_FILE_NAME) which seems
to work fine.  When my thread is awakened by the existence of a new file, I
use FindFirstFile/FindNextFile to get a list of all files matching my
filespec, sort them by creation time, and then process them one by one.

After processing a file, I delete it because I do not want it to get
processed again.  Deleting the file causes another change notification to be
sent to my application which results in another pass through the
FindFirstFile/FindNextFile loop, which (quite surprisingly!) discovers the
file again, even though it was supposedly deleted!!  The only thing that
makes any sense is that DeleteFile() must be returning before the file
system has actually deleted the file.  Is this really the case?  (caching
maybe?)

Now, I can use FILE_NOTIFY_CHANGE_LAST_WRITE as the NotifyFilter instead of
FILE_NOTIFY_CHANGE_FILE_NAME, and that still gives me notifications for new
files and does not give me the additional notifications for deleted files,
which is even better.  So while my intention is to use
FILE_NOTIFY_CHANGE_LAST_WRITE instead (since it would seem to be more
efficient, resulting in a 50% reduction in thread awakenings), I am still
curious about the delay in files getting deleted when calling DeleteFile().

- Dennis