もちろん、ファイルが空であるかどうかをテストする標準的な方法はを使用することですが、test -s FILE顧客の1人が次のテストを含むスクリプトを受け取りました。
RETVAL=`ls -s ./log/cr_trig.log | awk '{print $1}'`
if test $RETVAL -ne 0
then
echo "Badness: Log not empty"
exit 25
fi
ベンダーは、テストした両方の環境で動作すると主張します。言うまでもなく、私がテストした両方の場所で悲惨に失敗しました。
だから気になります。空のファイルはいつls -s印刷されますか0？
これまでに私が見つけたものは次のとおりです。
- LinuxのGFS：4
- Linuxのext4:0
- SolarisのZFS：1
- ソラリスのUFS：0
- AIXのjfs：0
- HP-UXのVxFS：0
- HP-UXのHFS：0
- Mac OS XのHFS：0
まだネットワークファイルシステムを調べたことがありません。
質問：他の人にスクリプトが次のようになることをエレガントに説明するにはどうすればよいですか？間違った？
「正しい」バージョンは次のとおりです。
if test ! -s ./log/cr_trig.log
then
echo "Badness: Log not empty"
exit 25
fi
ベストアンサー1
非常に興味深い発見です。ls -sファイルが空であることを確認するために使用したことはありませんが、空の0ファイルも報告するものとします。
あなたの質問に：もし人主テスト結果を表示するためにコメントを残してください。結果を説明するために、ls -s実際のサイズ（バイト）ではなくファイルシステムに割り当てられたブロック数を報告する状態。明らかに、一部のファイルシステムの実装では、inodeにNULLポインタを格納する代わりに、データを保存する必要がなくてもブロックを割り当てます。
これの説明はパフォーマンスに関連している可能性があります。空の空のファイルを生成することは、一般的な処理の例外です（私が見た最も一般的な用途は、ファイルの存在がソフトウェアの一部の状態を表す状態ファイルを生成することです）。
ただし、通常、生成されたファイルはいくつかのデータを非常に迅速に取得するため、特定のファイルシステム設計者はファイルが作成されたらすぐにデータブロックを割り当てて、最初のデータが到着したときにタスクがすでに完了するようにすることが価値があると思ったかもしれません。
2番目の理由は、ファイルに過去に削除されたデータが含まれているためです。最後のデータブロックを解放するのではなく、同じファイルで再利用できるようにデータブロックを保持します。
編集する：
もう一つの理由が浮かんでいます。値が0より大きいファイルシステムは次のとおりです。ZFS、RAID + LVM + FSの実装と政府財務大臣、クラスタ化されたファイルシステム。どちらも、inodeに保存されていないファイルの整合性を維持するためにメタデータを保存する必要があるかもしれません。ls -sこのメタデータに割り当てられたデータブロック内の数にすることができます。