如何应对“磁盘已满”的情况 场景？
绝大多数应用程序无法正确处理“磁盘已满”的情况。
示例：安装程序没有看到磁盘已满，忽略所有错误，最后高兴地宣布“安装完成！”，或者电子邮件程序不知道它刚刚下载的消息无法保存，并告诉服务器删除原来的。
有哪些技巧可以优雅地处理这种情况？ 你用它们吗？ 你测试它们吗？
The vast majority of applications does not handle "disk full" scenarios properly.
Example: an installer doesn't see that the disk is full, ignores all errors, and finally happily announces "installation complete!", or an email program is unaware that the message it has just downloaded could not be saved, and tells the server to delete the original.
What techniques are there to handle this situation gracefully? Do you use them? Do you test them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
作为用户，我希望软件能够：
#2不可能，请告诉我任何特殊要求。作为开发人员，实现此目的的技术包括：
As a user, I want software to:
#2is impossible, tell me about any special requirements.As a developer, techniques to do this include:
我在打开、写入或关闭文件时检查错误。 另一方面，我没有做任何特别的事情来处理“磁盘已满”错误。 相反，我依靠底层操作系统向我报告这些错误，就像它报告任何其他类型的错误一样。
I check for errors when I open, write to, or close a file. On the other hand, I don't do anything in particular to handle "disk full" errors. Instead, I rely on the underlying OS to report those errors to me in the same way it reports any other types of errors.
我使用数据采集软件。 由于我可以在创建文件之前估计文件的大小（基于请求获取的数据量），因此即使在创建文件之前，如果我预计空间不足，我也会根据存在的磁盘空间量发出警告。
I work with data acquisition software. Since I can estimate the size of a file before I create it (based on the amount of data requested to acquire), I warn even before I create the file based on how much disk space exists if I expect that I will run out of room.
将持久性例程构建在循环块内非常重要，提示用户选择位置然后尝试保存，直到数据正确保存或用户选择取消。 这对我来说似乎是显而易见的，但我见过很多应用程序在您尝试坚持甚至未处理的情况时遇到异常，并将执行推到例程之外并丢失内存中的数据。
It's important to structure your persistance routines to be within a block that loops, prompting the user to select a location then attempting to save, until either the data saves correctly or the user chooses to cancel. It seems obvious to me, but I've seen a lot of apps that hit an exception when you try to persist that isn't even handled and pushes execution up out of your routine and lose your in-memory data.
正如通常的情况一样，我在这个问题上的立场与传统思维相矛盾。
一般来说，我会忽略磁盘空间不足，就像忽略内存不足一样。 部分原因是不可能可靠地预测这些情况。 部分原因是，当我们谈论软件在意外情况下的行为时（例如您不知道自己存在的错误会导致您耗尽所有磁盘或内存），不可能充分推理这种情况并为其编写代码并测试它。 （可以肯定的是，如果您的代码未经测试，它就无法工作）。
但是，有一些特定条件表明采用不同的方法：
如果您保存着重要的未保存的用户状态（例如经过一些编辑的文本文件），请考虑在后台预先保存数据，以免崩溃稍后可恢复。
如果您要根据交互式用户的命令（例如“文件”->“保存”）写入磁盘，您可以捕获失败并让他们重试。
无论哪种情况，bug 看起来像 bug 都很重要。 崩溃的错误应该崩溃。 捕获意外异常并悄悄地继续会剥夺您的诊断机会，同时使您的软件处于不安全状态。
As is often the case, my position on this question contradicts conventional thinking.
In general, I ignore out-of-disk-space the same way I ignore out-of-memory. Partly because it's impossible to reliably predict these conditions. Partly because when we're talking about the behavior of software in unexpected conditions (like a bug you don't know you have which causes you to eat all disk or memory), it's impossible to reason well enough about the situation to code for it AND TEST IT. (It's safe to assume that if you have code that isn't tested, it doesn't work).
However, there are specific conditions that indicate a different approach:
If you're holding important, unsaved, user state (like a text file with some edits), consider pre-saving the data in the background, so that a crash is recoverable later.
If you're about to write to disk based on an interactive user's command (e.g. File->Save), you can catch a failure and offer to let them try again.
In either cases, it's important that bugs look like bugs. Crashing bugs should crash. Catching unexpected exceptions and continuing quietly robs you of diagnostic opportunities while leaving your software in an unsafe state.
为了进行测试，创建一个小分区，这些分区将在不同的点耗尽空间，也许作为虚拟 PC，以便测试得到良好的包含和重现。
For testing, create a small partitions that will run out of space at different points, perhaps as virtual PCs so that the tests are well-contained and reproducible.
为了进一步扩展这个问题，是否有在 SQL 服务器上处理“磁盘已满”的技术？ 我知道永远不应该发生，但它可以（并且已经发生在我身上）。
我熟悉独立 PC 应用程序上的磁盘已满测试（在软盘时代长大的编程）。 即使在空间非常紧张的较旧的 SCO Unix 系统上，如果空间不足就会冻结。 不太熟悉它在现代系统上的含义。
To extend this further, are there techniques for handling "disk full" on a SQL server? Should never happen I know, but it can (and has happened to me).
I'm familiar with testing for disk full on standalone PC apps (having grown up programming in the floppy disk era). Even on an older SCO Unix system that was very tight on space and would freeze if you ran it out of space. Not so familiar with what it means on a modern system.
你是完全正确的。 软件应该优雅地处理这种情况。
您始终可以检查 IOException 以查看磁盘是否已满或者用户是否有权写入该位置。
SQL Server 确实可以处理这种情况，但无法从中恢复。 当磁盘已满时...它会停止工作。 :)
You are totally right. Software should handle gracefully this kind of situation.
You can always check on an IOException to see if the disk is full or if the user have rights to write to that location.
SQL Server does handle this situation but doesn't recover from it. When the disk is full... it stops working. :)
我们刚刚在我们的产品中添加了对此的支持。 在嵌入式设备上运行时，我们每小时检查磁盘空间是否低于 20% (10mb)，并将警告传输到办公室服务器、记录问题并警告用户。
一旦处于这种状态，我们每两分钟检查一次 2mb 以下的空间，并优雅地停止应用程序（引导系统），并拒绝运行，直到空间问题得到解决。
由于我们的产品是客户工作场所的核心系统，因此引起了管理人员的关注。
We have just add support for this in our product. Running on an embedded device, we check disk space being below 20% (10mb) each hour, and transmit warnings to the office server, log the problem, and warn the user.
Once in this state we check every two minutes for sub 2mb space, and gracefully stop the application (a guidance system), and refuse to run until the space problem is solved.
As our product is a core system in our customers workplace, this gets the administers attention.
如果我正在编写一个应用程序，我可以让它以某种方式从 I/O 故障中恢复，但如果我正在运行其他人的应用程序，我必须采取不同的方法，即恢复尽可能多的磁盘空间。 这是我使用的方法。 可能存在大量可恢复磁盘空间，其形式如下：1) 少量大文件深深隐藏在模糊目录中，或 2) 大量小文件分散在磁盘上，同样位于不明显的位置。 此方法可以以任何一种方式找到它们。
If I'm writing an app, I can have it recover in some way from I/O failure, but if I'm running someone else's app, I have to take a different approach, which is to recover as much disk space as possible. This is the method I use. There can be large amounts of recoverable disk space in the form of 1) a small number of large files hidden away deeply in obscure directories, or 2) large numbers of small files dispersed over the disk, again in non-obvious locations. This method finds them either way.
是的，尝试对此类问题采取“聪明”的做法可能是一个非常糟糕的主意。 基本上你能做的就是尽量减少损失。 对于未保存用户数据的交互式应用程序，请尽量避免在用户有机会解决问题之前崩溃。
Yeah, it's probably a really bad idea to try to do something "smart" about this kind of problem. Basically the most you can do is try to minimize the loss. For interactive apps with unsaved user data, try to avoid crashing before the user has a chance to resolve the problem.