We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


CFile and Power Loss Situations

gbmgeor asked
Medium Priority
Last Modified: 2008-03-17
Using the code below I put a breakpoint AFTER the Close(), and I then pull the power on the machine. When I reboot the file has been deleted ! - Is this done by ChkDsk on restart (which is executed when clean shutdown does not take place) ?, Is this a bug ?, and finally is there a way I can prevent the file from being deleted ?

Note : It also has this behaviour when executing a release .exe (i.e. it does not have to be running under MSDEV for this to happen).

CFile f;
char* pFileName = "d:\\nt\\1300\\ned.nt1.1300\\tcq\\PRC00516.001";
strcpy(inp, "hello");
f.Open( pFileName, CFile::modeWrite | CFile::modeCreate );
f.Write( inp, sizeof(inp));
Watch Question

Unlock this solution with a free trial preview.
(No credit card required)
Get Preview

Opps I forgot a point I originally planned on mentioning.  If you open a file in a shared mode the OS will not be able to cache as well and most changes will have to be written to disk immediately.  If you use a mode like write exclusive with share read it is the same (as far as your program is concerned) as read and write exclusive.  But the OS will write out changes more quickly.


I agree about switching the power off as not being a very good "test", but if the file has already been Closed(), then surely NT should not go ahead and delete the file. If I break after the close then I can look at the contents of the file, and even delete (del) from within explorer, etc... All I am trying to do is convince a user that the problem is not in my code, but is a "problem" with the OS.

it is a "problem"  (definitly in quotes) with the OS.  It occurs because the OS caches directory and file system information.  As far as your program or any other program is concerned the file exists bacause they are looking at the cached data, not what is on disk.  Thus NT does not "go and delete the file" it just never gets around to storing the file and its contents in a permanent location--the disk.  Given time it would have.

I recommend you try flushing and opening in a sharable mode, both tend to help the OS get things to disk faster.  (actually they hinder keeping them in memory.)


I always thought that "closing" would flush the buffers. In fact quoting MS doc - "Use the Close member function. This function closes the file-system file and flushes buffers if necessary."

I will try using flush() (can't open in share mode), but I don't hold out much hope.

There is a cool FILE_FLAG_WRITE_THROUGH flag you use with the CreateFile() dwFlagsAndAttributes parameter that may help you here.

Unfortunately, in Microsoft's (should I say God-like?) wisdom there was no need provide this flag for the CFile class (as far as I can tell.)    But they did provide the flush() function which should correspond to the windows API FlushFileBuffers() and that should do what you want.  The FILE_FLAG_WRITE_THROUGH would be more convenient, though.

So did this help?


I've not been able to test using the Flush(), but given time I will give it a try. I had already informed the customer that switching the machine off was not considered a valid test, and if he considered the application to be that mission critical then he should invest in a UPS !

Thanks for your help....

PS : In another application where I use CreateFile() I've already had to use FILE_FLAG_WRITE_THROUGH because of another NT bug when writing to UNC Files :)
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.