アプリケーションの大部分は、「ディスクがいっぱい」のシナリオを適切に処理しません。
例: インストーラーは、ディスクがいっぱいであることを認識せず、すべてのエラーを無視し、最終的に喜んで「インストールが完了しました!」と通知します。または、メール プログラムは、ダウンロードしたばかりのメッセージを保存できなかったことを認識せず、サーバーに通知します。オリジナルを削除します。
この状況を適切に処理するには、どのようなテクニックがありますか? それらを使用しますか？それらをテストしますか？
2030 次
11 に答える
7
ユーザーとして、私はソフトウェアに次のことを望んでいます。
- 私のデータを保存します。
- 実際の作業を行う前に、できるだけ早く環境を検証します。
#2不可能な場合は、特別な要件について教えてください。- それ自体の後にクリーンアップします。
開発者として、これを行うためのテクニックは次のとおりです。
- 代替手段がない場合にのみ中止し、前の選択が失敗した場合にユーザーが新しい選択を行う機会を与えます (AgentThirteen の回答を参照) 。
- 必要なリソース (メモリ、ディスク容量、周辺機器) をできるだけ早く確認します。失敗が確実な場合はすぐに停止します。成功が不確実な場合は警告を表示し、ユーザーが続行するかどうかを選択できるようにします。
- リソースを事前に割り当てて、必要なときに引き続き使用できるようにします。
- ユーザーがアプリケーションをバックグラウンドに置き、他のツールを使用して問題を解決できるように、非モーダル ダイアログに警告とエラーを表示します。
- 「元に戻す」リストの維持: これまでに実行されたアクションの履歴。アプリケーションを中止する必要がある場合は、それらのアクションを元に戻す機会を提供してください。
于 2008-11-08T21:56:08.723 に答える
2
よくあることですが、この質問に対する私の立場は従来の考え方と矛盾しています。
一般に、メモリ不足を無視するのと同じように、ディスク容量不足を無視します。これらの状態を確実に予測することは不可能であるためです。その理由の 1 つは、予期しない状況 (ディスクやメモリをすべて消費してしまう原因となる、自分ではわからないバグなど) でのソフトウェアの動作について話している場合、その状況をコード化するのに十分な理由を説明することが不可能だからです。そしてそれをテストします。(テストされていないコードがある場合、それは機能しないと考えて間違いありません)。
ただし、別のアプローチを示す特定の条件があります。
保存されていない重要なユーザー状態 (一部の編集を含むテキスト ファイルなど) を保持している場合は、後でクラッシュを回復できるように、バックグラウンドでデータを事前に保存することを検討してください。
インタラクティブなユーザー コマンド (例: [ファイル] -> [保存]) に基づいてディスクに書き込もうとしている場合、失敗をキャッチして、再試行を許可することができます。
どちらの場合でも、バグがバグのように見えることが重要です。クラッシュするバグはクラッシュするはずです。予期しない例外をキャッチして静かに続行すると、診断の機会が奪われ、ソフトウェアは危険な状態のままになります。
于 2008-11-08T22:16:51.727 に答える
2
ファイルを開く、書き込む、または閉じるときにエラーをチェックします。一方で、「ディスクがいっぱいです」というエラーを処理するために、私は特に何もしていません。代わりに、基になる OS に依存して、他の種類のエラーを報告するのと同じ方法でこれらのエラーを報告します。
于 2008-10-31T20:04:06.457 に答える
2
私はデータ取得ソフトウェアを使用しています。ファイルを作成する前に (取得するように要求されたデータの量に基づいて) ファイルのサイズを見積もることができるので、空き容量がなくなることが予想される場合は、ファイルを作成する前に、存在するディスク容量に基づいて警告します。 .
于 2008-10-31T20:05:28.483 に答える
2
データが正しく保存されるか、ユーザーがキャンセルを選択するまで、ユーザーに場所を選択してから保存を試みるようにループするブロック内に永続化ルーチンを構成することが重要です。私には当然のことのように思えますが、永続化しようとすると例外が発生し、それが処理されず、ルーチンから実行が押し出され、メモリ内データが失われるアプリをたくさん見てきました。
于 2008-10-31T20:17:28.240 に答える
2
テストのために、さまざまな時点でスペースが不足する小さなパーティションを作成します。おそらく仮想 PC として、テストが十分に含まれ、再現可能になるようにします。
于 2009-12-02T17:37:53.117 に答える
0
アプリを作成している場合は、I/O 障害から何らかの方法で回復させることができますが、他の人のアプリを実行している場合は、別のアプローチを取る必要があります。つまり、できるだけ多くのディスク領域を回復することです。 . これは私が使用する方法です。回復可能な大量のディスク領域が、1) 目立たないディレクトリの奥深くに隠されている少数の大きなファイル、または 2) ディスク上に散らばっている多数の小さなファイルの形で存在する可能性があります。このメソッドは、どちらの方法でもそれらを見つけます。
于 2009-11-23T17:38:57.520 に答える
0
ええ、おそらく、この種の問題について「賢い」ことをしようとするのは本当に悪い考えです。基本的にできることは、損失を最小限に抑えることです。ユーザー データが保存されていない対話型アプリの場合は、ユーザーが問題を解決する前にクラッシュを回避するようにしてください。
于 2010-06-02T21:16:34.847 に答える
0
これに対するサポートを製品に追加したところです。組み込みデバイスで実行し、ディスク容量が 20% (10mb) 未満であることを毎時間チェックし、オフィス サーバーに警告を送信し、問題をログに記録し、ユーザーに警告します。
この状態になると、2 分ごとに 2 MB 未満のスペースをチェックし、アプリケーション (ガイダンス システム) を適切に停止し、スペースの問題が解決されるまで実行を拒否します。
当社の製品はお客様の職場のコア システムであるため、管理者の注目を集めています。
于 2009-04-16T00:49:45.530 に答える
0
これをさらに拡張するために、SQLサーバーで「ディスクがいっぱい」を処理する手法はありますか? 決して起こるべきではありませんが、起こる可能性があります（そして私に起こりました）。
私は、スタンドアロンの PC アプリでディスクがいっぱいになったかどうかをテストすることに精通しています (フロッピー ディスク時代にプログラミングを経験したことがあります)。スペースが非常に狭く、スペースがなくなるとフリーズする古い SCO Unix システムでも。現代のシステムでそれが何を意味するのかについてはあまり詳しくありません。
于 2008-10-31T20:02:32.387 に答える
0
あなたは完全に正しいです。ソフトウェアは、この種の状況を適切に処理する必要があります。
IOException をいつでもチェックして、ディスクがいっぱいかどうか、またはユーザーがその場所への書き込み権限を持っているかどうかを確認できます。
SQL Server はこの状況を処理しますが、回復しません。ディスクがいっぱいになると...動作が停止します。:)
于 2008-10-31T20:07:27.060 に答える