CFile::Remove fails [Resolved]

Mike Osbahr

Have had an app running for years and now suddenly it is unable to delete files. It is processing the data in the files. The only step it seems unable to complete now is the file deletion. I have checked the directory permissions and even recreated the directory. Has there been any recent Windows update that would make a call to CFile::Remove fail? Any other ideas what might be going on?

Thanx, >>>-----> MikeO

modified on Tuesday, May 25, 2010 1:48 PM

jeron1 · modified on Tuesday, May 25, 2010 1:48 PM

Is it throwing an exception? If so which one?

David Crow · modified on Tuesday, May 25, 2010 1:48 PM

Mike Osbahr wrote:

Any other ideas what might be going on?

Since CFile::Remove() is just a thin wrapper around DeleteFile(), why not call DeleteFile() directly? If it fails, call GetLastError() to find out why? This is what Remove() is doing when it throws an exception.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Man who follows car will be exhausted." - Confucius

Mike Osbahr

No exception is being thrown. The program reads the contents of the file into memory, deletes the file, and then processes the data. If an exception were being thrown the data would not be processed. I can clearly see in the database though that it is. The program has been running correctly about five years now. I am hoping somebody has an idea what I can check without having to modify the code.

Thanx, >>>-----> MikeO

jeron1

So you've got the call in a TRY/CATCH block?

David Crow

Mike Osbahr wrote:

...deletes the file...

So then what's the problem? :confused:

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Man who follows car will be exhausted." - Confucius

Mike Osbahr

The call is in a try/catch block. An exception should also write a message to the program log. The last entry in the log is "Program started".

Thanx, >>>-----> MikeO

Mike Osbahr

I was explaining how I know that no exception is being thrown. If CFile::Remove were throwing an exception the data would not be processed. The data is being processed but the files are not being removed. This causes the file processing loop to take longer each time and eventually the program fails. I'm looking for clues why CFile::Remove might not be working and not throwing an exception. The program has been working for five years. This is why I asked about Windows updates.

Thanx, >>>-----> MikeO

David Crow

Mike Osbahr wrote:

If CFile::Remove were throwing an exception the data would not be processed.

This implies that you are removing the file before processing it, correct?

Mike Osbahr wrote:

I'm looking for clues why CFile::Remove might not be working...

See here.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Man who follows car will be exhausted." - Confucius

Mike Osbahr

Perhaps you should read my posts. The data in the file is read into memory before I attempt to delete the file. I am trying to get help diagnosing why a long running program would fail without modifying the code. Since the read/delete/process occur in that order within the try/catch and the data is being processed, I know that CFile::Remove is not throwing an exception. Is there an error condition of DeleteFile() for which CFile::Remove would not throw an exception?

Thanx, >>>-----> MikeO

Luc Pattyn · modified on Tuesday, May 25, 2010 1:48 PM

Here is an hypothesis. It may seem far fetched, it has been proven correct many times already. A file gets created. By your app or another one, not really relevant. Pretty soon (very relevant) your app wants to read that file, no problem; wants to modify or delete that file, big problem. What happens is this: something is also interested in your fresh file, opens it with read intentions, but doing so also locks it for writing and deleting. Who does this? Any piece of code that wants to help you: an anti-virus package; an automatic indexer; Google Desktop; you name it. Remedy 1: wait 1 minute. Literally. Let the helpers do their work, then remove the file. Remedy 2: use a special folder, and put it on the exceptions list of the helper, if you can identify it. Why the sudden change? did you add such helper? did one of them become slower? did the load of your system increase recently, making everything run a bit slower? FYI: Windows Explorer is well aware of this phenomenon; if you give it a delete command, which fails, it will not tell you immediately; instead it will retry 5 times at 1 second intervals, and only if that still fails, it will tell you so. (And you can find a patch to modify that "5" in the registry, Google will provide the details). :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read formatted code with indentation, so please use PRE tags for code snippets.

I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).

Mike Osbahr

Thanks for the helpful suggestions. It turns out my observations were flawed. The CFile::Remove is working correctly. The data processing has slowed to a crawl and it appeared that the files accumulating was the cause. Instead it is the result. Have posted a query in the Database forum now. Thanks again.

Thanx, >>>-----> MikeO