🚀 go-pugleaf

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message
news:42c8c873$1@newsgroups.borland.com...
>
> "Dennis Jones" <nospam@nospam.com> wrote in message
> news:42c8b764@newsgroups.borland.com...
>
> > 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?)
>
> According to MSDN:
>
>     "The DeleteFile function marks a file for deletion on close.
Therefore,
> the file deletion does not occur until the last handle to the file is
> closed."

Remy,

Well, okay, except that by the time I call DeleteFile, I have already
finished processing the file and have closed it!

Interestingly enough however, I discovered that
FILE_NOTIFY_CHANGE_LAST_WRITE doesn't do what I want (the lpPathName
parameter doesn't seem to take filespec into consideration), so I went back
to FILE_NOTIFY_CHANGE_FILE_NAME, and now the original problem I described in
my first message is gone, but I think I know why:

I realized that I should not be trying to process the file until I am
certain that the creator/writer has finished writing it.  So, I added a wait
loop in which I attempt to open the file for exclusive access.  If the open
fails, I wait 50 ms and try again.  Eventually, the file owner will have
finished writing to the file and closed it, and the open will succeed.  At
that time, I can continue with the processing code, and then close the file.

If I take out the wait loop, the original problem comes back.  If I add a
short (10 ms or so) Sleep call immediately after DeleteFile, the problem
goes away again.  These two changes (wait for exclusive access, or a short
delay after DeleteFile) suggest that, even with a very small test file (only
5 bytes), the OS is sending a change notification very quickly (upon file
creation), during which I was able to process (which is currently a
do-nothing function) and invoke DeleteFile before the owner (notepad.exe)
had actually completed the write/close operations, after which the OS sent
another change notification (name change perhaps?), causing my processing
loop to execute again.

Thus, since I must use a wait loop to avoid premature processing, I feel
fairly confident that I won't have to worry about this problem any more.
What do you think?  Would you agree?

- Dennis