文件操作函数返回,但在Windowsclosures时不实际提交

我正在一个MFC应用程序,可以(除其他外)用于closuresWindows。 当这样做时,Windows当然会将WM_QUERYENDSESSION和WM_ENDSESSION发送给所有的应用程序,包括我的。 但是,问题在于我的应用程序(作为一些析构函数的一部分)删除了在执行过程中使用过的某些文件(使用CFile :: Remove)。 我有理由相信,当Windowsclosures应用程序时,会调用析构函数(但难以确定)。

但是,当Windows重新启动时,我偶尔会注意到应该删除的文件仍然存在。 即使程序的执行是相同的(我有一个用于testing的脚本),这种情况并不会一致发生。 这导致我认为发生以下两件事之一:或者a)析构函数没有被一致地调用,或者b)Remove函数返回,但是在Windowsclosures之前文件并没有真正被删除。

目前唯一的解决方法是,如果我的程序停止后,系统等待大约10秒钟的关机,那么这些文件将被正确删除。 这使我相信,b)可能是这样的。

我希望有人能够帮助我解决这个问题。

关心Mort

Solutions Collecting From Web of "文件操作函数返回,但在Windowsclosures时不实际提交"

一旦您的程序从WM_ENDSESSION返回,Windows可以随时终止它:

如果会话正在结束,则该参数为TRUE; 会话可以在所有应用程序从处理该消息返回之后的任何时候结束。

如果会话很快结束,那么它可能会在析构函数运行之前结束。 WM_ENDSESSION返回之前,您必须先完成所有的清理工作,因为不能保证您有机会在之后完成清理工作。

这里的问题是,有些版本的Windows报告说文件处理操作已经完成了。 除非关闭被触发,否则这不是问题,因为包括文件删除在内的一些操作将被废弃。

我建议你通过强制你的代码在调用系统关闭之前等待文件的确认删除(有一个进程查找文件并在事件发生时提出一个事件)来应付这个问题。

如果系统正常关闭(螺母突然断电等),则所有缓存的数据都将被刷新。 特别是这包括刷新全局文件描述符表(或者在你的文件系统中调用的任何文件描述符表),它应该提交文件删除。

所以问题似乎是用户模式代码不会调用DeleteFile ,或者失败(无论什么原因)。 请注意,应用程序(进程)可能有几种方式可以退出,但并不总是被调用。 有自动对象在其调用堆栈的上下文中被销毁,还有全局/静态对象,它们被CRT初始化/清除代码初始化和销毁​​。

以下是终止过程的简要总结,其结果是:

  • 所有进程线程按照惯例退出(从其程序返回)。 OS终止没有线程的进程。 所有的人都被执行了。
  • 有些线程通过ExitThread退出或被TerminateThread 。 这些线程的自动对象是不可修改的。
  • ExitProcess退出进程。 自动对象不被破坏,全局可能被破坏(在CRT中发生这种情况是在DLL中使用)
  • 进程由TerminateProcess 。 所有的人都不叫。

我建议你检查是否确实调用了DeleteFile (或CFile::Remove这个包装它),并检查它是否成功。 例如,无论出于何种原因,您可能会打开同一个文件两次