ファイルへの書き込みアクセスを非侵襲的にテストする方法は？

シェルスクリプトで、実際にファイルを変更せずに、ファイルへの書き込みアクセスを簡単かつ非侵襲的にテストするにはどうすればよいですか？

の出力を解析することはできましたがstat、実装と時間によって統計出力がどれだけ異なるかはわかりませんが、それは本当に複雑で、おそらく壊れやすいようです。

ファイルの最後に追加して、それが成功するかどうかを確認することもできますが、考えられる2つの理由から、潜在的に危険です。

1. ここで追加を削除する必要があり、他のプロセスがファイルに書き込む場合、私の行が最後ではないため、これはすぐに重要になります。
2. ファイルを読み取るプロセスには、そのファイルの内容に関する任意の要件がある場合があり、そのアプリケーションが壊れている可能性があります。

ユーティリティの- wフラグを使用するだけtestです：

[ -w /path/to/file ] && echo "writeable" || echo "write permission denied"

後でファイルに書き込む場合は、まだ書き込みできない可能性があることに注意してください。ファイルが移動した、許可が変更された、などの可能性があります。-w書き込み許可を検出することもありますが、ファイルを書き込み不可にするために他の要因が介入します。

別のアプローチ：

if >> /path/to/file
then
    echo "writeable"
else
    echo "write permission denied"
fi

これは、追加のためにファイルを開こうとし、それが成功した場合、 コマンドを実行しません（つまり、nullコマンドを実行します）、ファイルへの出力で）。 

空のファイルが存在しない場合は作成されることに注意してください。

コマンドの-wオペレーターはtest単にa stat を実行してから、アクセスする必要があるように見えるかどうかを把握しようとします。私の代替手段（上記）はtest、アクセスチェックをシェルではなくカーネルによって強制するため、いくつかの特別な条件でのアプローチよりも信頼性が高くなります。例えば、

• ファイルが非UNIXファイルシステム上にある場合-特に非Unixファイルサーバーからリモートでマウントされている場合- stat誤解を招くモード値を返す可能性があるため。
• ファイルが読み取り専用でマウントされているファイルシステムにある場合。
• ファイルにACLがあり、モードによってアクセス権があるように見えるが、ACLがそれを拒否する場合、またはその逆の場合。
• セキュリティフレームワーク（AppArmor、SELinuxなど）がファイルへのアクセスを拒否する場合。

G-manは正しい。常に真実を語る[ -w ]わけではない。ここに存在しないファイルとシェルからの許可拒否メッセージに対処するため：

( [ -e /path/to/file ] && >> /path/to/file ) 2> /dev/null && 
  echo writable || 
  echo not writable

更新：恐ろしいですね。まあ、そうです。うーん...それをどのように表現するか...これを使用しないでください。ステファンのコメントを参照してください。

結論は何ですか？[ -w ]本当のことを言わなくても、それは仕事をすることを目的とする1つのコマンドです。そうでなければ、私たちはそれを非難し、バグレポートを書きます、そしてそれは将来機能します。動作し、使用する条件をよりよく確認してください[ -w ]。特別な場合のために特別なコードを書きます。回避策には独自の条件があります。

[ -w /path/to/file ]

先験的に最高です。