如何应对“磁盘已满”的情况?

作为用户,我希望软件能够:

1. 保留我的数据。
2. 尽早验证我的环境, 之前 我做任何真正的工作。
3. 如果 #2 是不可能的, 告诉我 关于任何特殊要求。
4. 自己清理。

作为开发人员,实现这一点的技术包括:

1. 流产 只有 如果没有其他选择,并且允许用户在前一个选择失败时做出新的选择(请参阅agenthirten的答案)。
2. 尽早检查所需资源(内存、磁盘空间、外围设备)。如果失败是确定的,则立即停止;如果成功是不确定的,则显示警告,允许用户选择是否继续。
3. 预先分配资源以确保 仍然 在需要时提供。
4. 在中显示警告和错误 非模态对话框 因此,用户可以将应用程序放在后台,并使用其他工具来解决问题。
5. 维护“撤消”列表:迄今为止已执行的操作的历史记录。如果应用程序必须中止,请提供撤消这些操作的机会。

打开、写入或关闭文件时检查是否有错误。另一方面,我不做任何特别的事情来处理“磁盘已满”错误。相反,我依靠底层操作系统向我报告这些错误,就像它报告任何其他类型的错误一样。

我使用数据采集软件。因为我可以在创建文件之前(基于请求获取的数据量)估计文件的大小,所以即使在创建文件之前,我也会根据磁盘空间的大小发出警告,如果我希望文件空间不足的话。

重要的是要将持久性例程构建在循环的块中,提示用户选择一个位置,然后尝试保存,直到数据正确保存或用户选择取消。在我看来这很明显,但是我看到过很多应用程序在你试图坚持的时候遇到了异常,这些应用程序甚至没有被处理,会把执行过程从你的程序中推出来,并丢失你的内存数据。

像通常情况一样,我在这个问题上的立场与传统思维相矛盾。

一般来说,我忽略磁盘空间不足,就像忽略内存不足一样。部分原因是无法可靠地预测这些条件。部分原因是,当我们谈论软件在意想不到的情况下的行为时(比如一个你不知道你拥有的导致你吃掉所有磁盘或内存的bug),就不可能充分地解释这种情况,为它编码并测试它。(可以安全地假设,如果您有未经测试的代码,那么它将不起作用)。

但是,有一些特定的条件表明采用了不同的方法:

• 如果您保存的是重要的、未保存的用户状态(如经过编辑的文本文件),请考虑在后台预保存数据,以便稍后恢复崩溃。

• 如果您要根据交互式用户的命令(例如,文件->保存)写入磁盘,则可以捕获故障并建议让他们重试。

在这两种情况下,bug看起来像bug都很重要。崩溃的虫子会崩溃。捕获意外的异常并继续悄悄地剥夺您的诊断机会,同时使您的软件处于不安全状态。

对于测试,创建一个小分区,该分区将在不同的点上耗尽空间,可能是作为虚拟PC,以便测试得到良好的包含和可复制性。

为了进一步扩展这一点,是否有在SQL服务器上处理“磁盘已满”的技术?我知道不应该发生,但它可以发生(而且发生在我身上)。

我熟悉在独立的PC应用程序上测试磁盘是否已满(在软盘时代已经长大了)。即使是在一个旧的sco-unix系统上,这个系统空间非常紧张,如果耗尽空间,它也会冻结。不太熟悉现代系统的意义。

你完全正确。软件应该能很好地处理这种情况。

您可以随时检查IOException,查看磁盘是否已满,或者用户是否有权写入该位置。

SQL Server确实处理了这种情况,但无法从中恢复。当磁盘已满时…它停止工作。:)

我们在产品中添加了对此的支持。在嵌入式设备上运行时,我们每小时检查磁盘空间是否低于20%(10MB),并将警告发送到Office Server,记录问题并警告用户。

在这种状态下,我们每两分钟检查一次低于2MB的空间,然后优雅地停止应用程序(一个引导系统),直到空间问题解决后再拒绝运行。

由于我们的产品是我们客户工作场所的核心系统,这引起了管理人员的注意。

如果我在写一个应用程序,我可以让它在某种程度上从I/O故障中恢复,但是如果我在运行别人的应用程序,我必须采取另一种方法,那就是尽可能多地恢复磁盘空间。 This is the method I use. 可以有大量的可恢复磁盘空间,其形式为:1)少量大文件隐藏在不清晰的目录中,或者2)大量小文件分散在磁盘上,同样位于不明显的位置。无论哪种方法都能找到它们。

是的,尝试做一些“聪明”的事情来解决这类问题可能是一个非常糟糕的主意。基本上你能做的就是尽量减少损失。对于具有未保存用户数据的交互式应用程序,请尝试在用户有机会解决问题之前避免崩溃。