绝大多数应用程序无法正确处理“磁盘已满”情况。
示例:安装程序没有看到磁盘已满,忽略所有错误,最后高兴地宣布“安装完成!”,或者电子邮件程序不知道它刚刚下载的消息无法保存,并告诉服务器删除原件。
有什么技巧可以优雅地处理这种情况?你用它们吗?你测试它们吗?
绝大多数应用程序无法正确处理“磁盘已满”情况。
示例:安装程序没有看到磁盘已满,忽略所有错误,最后高兴地宣布“安装完成!”,或者电子邮件程序不知道它刚刚下载的消息无法保存,并告诉服务器删除原件。
有什么技巧可以优雅地处理这种情况?你用它们吗?你测试它们吗?
作为用户,我希望软件能够:
#2
不可能,请告诉我任何特殊要求。作为开发人员,执行此操作的技术包括:
我在打开、写入或关闭文件时检查错误。另一方面,我没有做任何特别的事情来处理“磁盘已满”错误。相反,我依靠底层操作系统向我报告这些错误,就像它报告任何其他类型的错误一样。
我使用数据采集软件。因为我可以在创建文件之前估计文件的大小(基于请求获取的数据量),所以我什至在创建文件之前就根据存在的磁盘空间发出警告,如果我预计我会用完空间.
将持久性例程构建在循环的块内非常重要,提示用户选择一个位置然后尝试保存,直到数据正确保存或用户选择取消。这对我来说似乎很明显,但我已经看到很多应用程序在您尝试持久化时遇到异常,甚至没有处理,并将执行推到您的例程之外并丢失您的内存数据。
通常情况下,我在这个问题上的立场与传统思维相矛盾。
通常,我忽略磁盘空间不足的方式与忽略内存不足的方式相同。部分原因是不可能可靠地预测这些情况。部分原因是当我们谈论软件在意外情况下的行为时(比如你不知道自己有一个导致你吃掉所有磁盘或内存的错误),不可能对这种情况进行足够好的推理来为它编写代码并测试它。(可以安全地假设,如果您有未经测试的代码,它就不起作用)。
但是,有一些特定条件表明了不同的方法:
如果您持有重要的、未保存的用户状态(例如带有一些编辑的文本文件),请考虑在后台预先保存数据,以便以后可以恢复崩溃。
如果您要根据交互式用户的命令(例如 File->Save)写入磁盘,您可以捕获失败并提供让他们再试一次。
在这两种情况下,重要的是错误看起来像错误。崩溃的错误应该崩溃。捕获意外异常并继续悄悄地剥夺您的诊断机会,同时使您的软件处于不安全状态。
对于测试,创建一个小分区,在不同的点会用完空间,可能是作为虚拟 PC,以便测试得到很好的包含和可重复性。
为了进一步扩展这一点,是否有在 SQL 服务器上处理“磁盘已满”的技术?我知道永远不应该发生,但它可以(并且已经发生在我身上)。
我熟悉在独立 PC 应用程序上测试磁盘已满(在软盘时代长大的编程)。即使在空间非常紧张的旧 SCO Unix 系统上,如果你用完空间就会冻结。不太熟悉它在现代系统中的含义。
你是完全正确的。软件应该优雅地处理这种情况。
您可以随时检查 IOException 以查看磁盘是否已满或用户是否有权写入该位置。
SQL Server 确实可以处理这种情况,但不能从中恢复。当磁盘已满...它停止工作。:)
我们刚刚在我们的产品中添加了对此的支持。在嵌入式设备上运行,我们每小时检查磁盘空间低于 20% (10mb),并向办公室服务器发送警告,记录问题并警告用户。
一旦处于这种状态,我们每两分钟检查一次小于 2mb 的空间,然后优雅地停止应用程序(引导系统),并拒绝运行,直到空间问题得到解决。
由于我们的产品是客户工作场所的核心系统,因此会引起管理人员的注意。
如果我正在编写一个应用程序,我可以通过某种方式从 I/O 故障中恢复它,但如果我正在运行其他人的应用程序,我必须采取不同的方法,即尽可能多地恢复磁盘空间. 这是我使用的方法。可以有大量可恢复的磁盘空间,其形式为 1) 少量大文件深深地隐藏在不起眼的目录中,或 2) 大量小文件分散在磁盘上,同样位于不明显的位置。这种方法可以找到它们。
是的,尝试对这类问题做一些“聪明”的事情可能是一个非常糟糕的主意。基本上你能做的就是尽量减少损失。对于未保存用户数据的交互式应用程序,请尽量避免在用户有机会解决问题之前崩溃。