[FDclone-users:00308] Re: FDclone 2.05g has been released

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20040707120422.3F37253D0F@yuka.unixusers.net>
        Takashi SHIRAI <shirai@unixusers.net>writes:
> 　しらいです。

　FDclone 2.05g の変更点を解説します。


> 	ディレクトリ指定時の起動オプションが効いていなかった点を修正。

　[FDclone-users:00303] に書いてあるとおりです。


> 	ファイル名補完時のソート順がおかしかった点を修正。

　filename 補完時に複数の候補があると候補一覧が表示されます
が、補完候補 directory name に「/」を追加した形で sort され
てしまっていました。
　例えば「../」の次に「./」が来たり、普通の sort 順と違った
ために不審に思われた方もいたことでしょう。


> 	UNIX 版から組込みコマンド mkdir/rmdir を削除。

　[FDclone-users:00304] で指摘のあったとおりです。disable に
するだけで済ませようともしたんですが、ややこしいし無意味なの
で UNIX 版からは存在そのものを消しておきました。
　多分弊害はないと思いますが、何か不都合があれば報告お願いし
ます。

　ちなみに [FDclone-users:00288] で予告した enable と builtin
ですが、こっそり実装済です。但し、この二つは最初から disable
になってるので誰にも使えませんが。
　source 見て判る人は enable にして使ってみて下さい。


> 	SIGSTOP/SIGCONT を独自に操作する kernel に対応。

　こんな要らぬお節介をするのははっきり言って Zaurus 以外に存
在しないような気もするんですが、やっぱ Zaurus 使いには使い勝
手が悪くて仕方がないので shell 側で対応することにしました。

　Zaurus では電源ボタンによる suspend 時に全ての process に
SIGSTOP を送ります。同様に resume 時には SIGCONT を送り再開
させます。
　この措置が、job control を行なっている shell には災いしま
す。SIGSTOP は自身で catch したり無視したり出来ず、親 process
だけが感知出来るからです。
　shell は子 process に SIGSTOP が送られたことを察知すると、
子 process が suspend され端末を失ったと思い、一旦子 process
に受け渡した端末制御を自分の元に戻します。
　普通の SIGSTOP であれば、この後 shell 側から fg や bg を実
行することで子 process は再開し、fg の場合には端末制御も再び
子 process に受け渡されます。
　ところが Zaurus のようなケースでは、親 process の shell が
子 process に送られた SIGSTOP に気づいた頃には既に kernel に
よって子 process は SIGCONT を送られ再開しています。
　なので、その状態で子 process から端末制御を奪ってしまうと、
端末を失って子 process が SIGTTIN/SIGTTOU で suspend されて
しまいます。
　このため、shell から子 process を起動したままの状態で電源
ボタンによる suspend を行なうと、resume 時に子 process が再
開出来ません。

　bash や ash の実装では、set +m を行ない job control を禁止
することでこの問題に対処するしかなく、この対処では ^Z も使え
ません。これはこれまでのFDclone の実装も同様です。
　ただ、FDclone の実装では、自身が SIGCONT で復帰する時に端
末状態を reset する機能あるので、bash よりは被害の少ない状況
になっていました。これが 2.02b での suspend 時の対処です。
　今回の対処はそれをもう一歩進め、自分が suspend から resume
した痕跡を感知した場合には、子 process に送られた SIGSTOP を
無視する実装にしました。
　これにより、bash でなく FDclone を login shell にしている
限り、Zaurus 上で suspend した際にも子 process が resume さ
れるようになりました。

　但し、この措置は Zaurus 以外の一般の環境では弊害を生みます。
FDclone が suspend されている最中に子 process に SIGSTOP を
送った「何か」が Zaurus kernel でない場合、誰も SIGCONT で子
process を再開してくれないからです。
　例えば、FDclone から子 process を起動している状態で、別の
端末から親→子の順で SIGSTOP を送って両者を suspend させ、そ
の後 FDclone の方にだけ SIGCONT を送って resume したとします。
　この状況は FDclone から見ると Zaurus kernel が suspend →
resume した状況と全く区別がつかないため、同様に子 process の
SIGSTOP を無視してしまいます。
　その結果、FDclone は子 process の終了を待ち続けますし、子
process は suspend されて何も出来ませんし、この端末からは何
も出来ない状態になってしまいます。
　この状況を回避するには、SIGSTOP を送った時のように別の端末
から子 process に SIGCONT を送ってやるしか手はありません。

　このように弊害の可能性がない訳ではないのですが、現実問題と
しては SIGSTOP は意図的に送らないと発生しませんので、そうい
う意図的な操作を行なえる環境では SIGCONT を送るという回避策
もある筈で、大きな問題にはなり得ないと判断しました。
　本来の対処法は Zaurus kernel hack だと思うのですが、そうい
う措置を出来る人は非常に限られているので、敢えて小さな支障を
無視して大きな利得を取ることにしています。
　この件についても、何か支障あるようでしたらご報告お待ちして
おります。

                                               しらい たかし