https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/48806
というやつがあります。

お二方返信ありがとう御座います。
とりあえず、dosfstoolsを削除しようかと思っています。
尚、リネームされたファイルがあるフォルダのエントリには不整合が発生するようで、ファイルを削除してもエントリには問題があるという旨がchkdskで検出されます。　エントリ自体の整合性は、chkdsk /fで修正され、リネームされたファイルもBMP一つだけですが、Ubuntu側からは参照できているので、名前の再変更で復旧は出来そうですが、元ファイル名が無くなることになるので数があると気分的にはやる気が失せますね。

該当ファイルへはWindows側からは、全くアクセスできなくなりますので、Windowsにも不慣れな人が運悪く引っかかってしまうとかなり慌てる様な気はします。
運悪く似たような状況に陥った人の参考にでもなればいいのですが。

gnome-mountは何でも認識しようとするようで、事後にFreeBSDを入れたのですが、スライスも(中身は読めませんが)リムーバブル領域として列挙されています。
また、マウント作業を行う場合無条件にrwでマウントしようとしているようです。
事故を防ぐためにデフォルトはroで認識するようには出来ないのでしょうか？
ntfsもrwでマウントされますが、パフォーマンスが要らないアーカイブなどは圧縮属性になっていたりするので、うっかり誤操作で触った場合には不安が残ります。

報告としての意味合いが強く、起こることが解っているのなら運用で気をつければ良いかとは思っているのですが、インストール直後のデフォルト設定は安全よりになっていた方が良いような気はするのですが、難しいのでしょうかね？

最後の編集者: Crush (2009-02-12 01:36:03)

タイトルについては、Subjects cannot be longer than 70 characters. と表示され、更新できませんでした。
元の名前より短くしても駄目だったので諦めてしまいました。

インストール直後については、リブートしたXPは平気でしたので、恐らく先回りして、fstabに記述してしまうのも一つの解だと思うのですが、私の場合は、基本領域を各々独立させて使いたかったので、選択肢としてありませんでした。
お互いにお互いの状態を明示的に持たせた場合構成を変更したときに面倒くさいなぁという思いからの個人的な慣習ではありますが。
そういった理由で、MBRにはチェインローダ、GRUBはパーティションのブートブロックに書き込んでいます。
ですのでパーティションなどのマスクを行っていない場合の挙動はわからないのですが、ロジックではなく、実行した結果から言えば、マスクしたFAT32パーティションは、fstabには追記されず、デフォルトでは、gnome-mountによってリムーバブル領域として「認識」され、GUI等でクリックするなどして開いてしまえば「マウント」される。という所までは確認しています。
マウント処理がメニューとしても出るので、自動では「マウント」ではなく「マウント可能な場所として列挙されるだけ」の様には見えます。
fsckによるものかどうかは、現象としてそうなるという結果からの類推ですので、同じような事を別の物がしているのであれば、更に犯人が潜伏しているということにもなります。
とくにデフォルトから変更していないという以上の設定がどうなっているか、どのような設定が可能であるかは私には解りませんので、確実なfsckの回避方法があれば良いのですがと記述しました。
提示が必要であれば、Ubuntuパーティションは事故に気がついた後のままですので、設定やログは残っていれば出せますが、該当する場所を私は知らないです。
fsckの実行タイミングが全部解れば運用で引っかかる物は無いか思い出しては見ますが、fstabには、sda3と、光学ドライブしか列挙が無いため、マウント処理を行いそうな物というと、gnome-mountしか、現状思い当たらず、これと誤操作によるマウントは誤って運用上実行している可能性があるという状態です。

なにぶん、トリガやタイミングの確実な特定は出来ていないので、こういうインストールをして、運用していると現象が出るようですという話でしか今のところはなく、そのために一応必要そうなインストール時の状況を書いてあります。
本物のリムーバブルデバイスは取り外されてしまうことが多く、リネームされたと泣いている人の数と利用者を考えた場合、常時接続されていなければ問題は出ていないのではないかという気はします。

こちらで変更されてしまったFAT32パーティションについては、
・/にあるエントリ数は28。
・ext3のパーティションを三つ目の基本領域に持っている。
・fstabに記述は無い。
という条件です。従って、ファイルの数、ext3パーティションの存在は回避にならないかと思います。
roでマウントするのであれば、書き込みは行わない筈ですので、必然的に改竄もない物と思います。
起動回数によってfsckが走るのはext2とかでしたっけ？
FAT32を走査し、fsckを実行する条件がどこかにあると思うのですが･･･。
どなたかご存じないでしょうか？

思いつきで発言することをお許し下さい．
結果についての責任は持てません．

ack による投稿:

/sbin/dosfsck
/sbin/fsck.msdos
/sbin/fsck.vfat

を実行できないように(パーミッション剥奪、ダミーファイル置換等)してしまう、というのは当面の対処としていかがでしょうか。

ログを残すシェルスクリプトと置換するのはどうでしょう．
何処から起動されたかを調べる材料が手に入るかもしれません．
8.04 ではfsck.msdos　と fsck.vfat は dosfsck へのシンボリックリンクです．
8.10 でも同じであれば dosfsck のみを置換すれば済みます．

#! /bin/bash
### /root/dosfsck.log にログを残す
logfile=/root/dosfsck.log
### 日付，起動スクリプト名とコマンド引数，親プロセスID 
date >> $logfile
echo "$0 $*" >> $logfile
echo $PPID >> $logfile
### pstree なら親プロセスが何か解る？
pstree -Aap >> $logfile
### その他調査の手がかりとなる情報を記録


### エラー出力に何か書き込む．
### rc スクリプトから起動された場合/var/log のどこかに跡を残せる可能性あり．
echo "This is a dummy DOSFSCK" >&2

### 失敗ステータスで終了する -- 危険？？
### これも/var/log のどこかに跡を残せるかも
# exit 1
### 成功ステータスで終了
exit 0

参考：/sbin/fsck.nfs が initscripts 所属のダミーのシェルスクリプトです．

スクリプト内のダブルクォーテーションを修正

最後の編集者: einundzwanzighundertsechs (2009-02-14 15:52:35)

FATのディレクトリのうち、ルートはサイズが固定です。
8.3形式で512個のエントリしか無く、vfatでは更に登録できるファイルは減少します。
ですので、ルートにフォルダをおくべきではないという話になっていたのではないかと。
マウントの回数、経過時間当たりで何か起こしているのかもしれませんね。
ログを残すようにしてわざと怪しい作業してみるしか捕まえる方法は無いかもしれないです。