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

文件 *** 作函数返回,但在Windowsclosures时不实际提交,第1张

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

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

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

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

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

有没有办法减lesslinux作业中的I / O等待时间?

为什么可执行文件和可链接格式(ELF)文件包含一组节?

为什么我在这里得到一个SIGABRT?

C ++ ofstream在程序崩溃时的行为

如何创build名称不同的目录? (区分大小写的CreateDirectory函数)

关心Mort

Matlab加载函数超时

^ Z字符是否写入文件?

批处理脚本删除重复的行,但想忽略/跳过一些行

阅读越来越多的文件

如何看到类似“lsof -l”的文件句柄?

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

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

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

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

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

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

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

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

所有进程线程按照惯例退出(从其程序返回)。 OS终止没有线程的进程。 所有的人都被执行了。

有些线程通过ExitThread退出或被TerminateThread 。 这些线程的自动对象是不可修改的。

ExitProcess退出进程。 自动对象不被破坏,全局可能被破坏(在CRT中发生这种情况是在DLL中使用)

进程由TerminateProcess 。 所有的人都不叫。

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

总结

以上是内存溢出为你收集整理的文件 *** 作函数返回,但在Windowsclosures时不实际提交全部内容,希望文章能够帮你解决文件 *** 作函数返回,但在Windowsclosures时不实际提交所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/1290517.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-09
下一篇 2022-06-09

发表评论

登录后才能评论

评论列表(0条)

保存