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

Question

绝大多数应用程序无法正确处理“磁盘已满”方案。

示例：安装程序没有看到磁盘已满，忽略所有错误，最后愉快地宣布“安装完成！”，或者电子邮件程序不知道它刚下载的消息无法保存，并且告诉服务器删除原始文件。

有什么技巧可以优雅地处理这种情况？你用它们吗？你测试它们吗？

Answer 1

作为用户，我想要软件：

1. 保留我的数据。
2. 尽早验证我的环境，之前我做任何实际的工作。
3. 如果#2不可能，告诉我有关任何特殊要求。
4. 自行清理。

作为开发人员，执行此操作的技巧包括：

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

Answer 2

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

Answer 3

我使用数据采集软件。因为我可以在创建文件之前估计文件的大小（基于请求获取的数据量），所以即使在我根据存在多少磁盘空间创建文件之前我也会发出警告，如果我预计我将耗尽空间

Answer 4

将持久性例程构建在循环的块内是很重要的，提示用户选择一个位置然后尝试保存，直到数据保存正确或用户选择取消。对我来说这似乎是显而易见的，但是我看到很多应用程序在您尝试保持甚至没有处理时会遇到异常并将执行推出日常工作并丢失内存数据。

Answer 5

通常情况下，我对这个问题的立场与传统思维相矛盾。

一般来说，我忽略了磁盘空间，就像忽略内存不足一样。部分是因为不可能可靠地预测这些条件。部分是因为当我们谈论软件在意外情况下的行为时（比如你不知道有什么导致你吃掉所有磁盘或内存的错误），就不可能对这种情况做出充分的理由来编写代码。并测试它。 （可以安全地假设，如果您的代码未经过测试，则无效）。

但是，有一些特定的条件表明了不同的方法：

• 如果您持有重要的，未保存的用户状态（如带有一些编辑的文本文件），请考虑在后台预先保存数据，以便以后可以恢复崩溃。

  < / LI>

• 如果您要根据交互式用户的命令（例如文件 - >保存）写入磁盘，您可以发现故障并提供让他们再试一次。

在任何一种情况下，错误看起来像bug都很重要。崩溃的bug应该崩溃。捕获意外的异常并继续悄悄地让您失去诊断机会，同时让您的软件处于不安全的状态。

Answer 6

为了进行测试，创建一个小分区，这些分区将在不同的点上耗尽空间，可能作为虚拟PC，以便测试具有良好的包含性和可重现性。

Answer 7

为了进一步扩展，有没有在SQL服务器上处理“磁盘已满”的技术？我不应该知道，但它可以（并且发生在我身上）。

我熟悉在独立PC应用程序上测试磁盘已满（在软盘时代已经长大了编程）。即使是在较旧的SCO Unix系统上，如果你在太空中运行它，它在空间上会非常紧张。对现代系统的含义不太熟悉。

Answer 8

你完全正确。软件应该优雅地处理这种情况。

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

SQL Server确实处理了这种情况，但没有从中恢复。当磁盘已满时......它将停止工作。 ：）

Answer 9

我们在产品中添加了对此的支持。在嵌入式设备上运行时，我们每小时检查磁盘空间低于20％（10mb），并向办公室服务器发送警告，记录问题并警告用户。

一旦处于这种状态，我们每2分钟检查一次2mb空间，并优雅地停止应用程序（引导系统），并拒绝运行直到空间问题得到解决。

由于我们的产品是客户工作场所的核心系统，因此需要管理人员注意。

Answer 10

如果我正在编写应用程序，我可以通过某种方式从I / O故障中恢复，但如果我正在运行其他人的应用程序，我必须采取不同的方法，即恢复尽可能多的磁盘空间尽可能。 This is the method I use.可以存在大量可恢复的磁盘空间，其形式为：1）隐藏在模糊目录中的少量大文件，或2）分散在磁盘上的大量小文件，同样在非明显的位置。这种方法可以找到它们。

Answer 11

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