asked on

CFile and Power Loss Situations

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));
f.Close();

ASKER CERTIFIED SOLUTION

nietod

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

nietod

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.

gbmgeor

ASKER

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.

nietod

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.)

gbmgeor

ASKER

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.

warmcat

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

nietod

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.

nietod

So did this help?

gbmgeor

ASKER

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 :)