[FDclone-users:00546] Re: FDclone 2.08f has been released

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

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

> 　本日 fj.sources に FDclone 2.08f の patch を投稿しましたの
> でご案内申上げます。full package は以下の URL で順次公開され
> ていくと思います。

　2.08e の時に「最後の総決算」と言っておきながらこの体たらく。
しかも、release した直後にも拘らず既に bug 報告が届いていま
す。
　みなさんも 2.09 release までにせいぜい bug 探しに努めて下
さい。

　では、今回の変更点の解説です。


> 	NFS 上の履歴セーブファイル保護用にファイルロックに対応。

　NFS 上では fcntl lock が使えないので、従来の実装ではロック
をせずに上書きで壊れたら諦めるという投げやりな対応をしていま
した。
　でも、NFS 上に $HOME があるってことは複数人でアカウント共
有ということが十分に予想される訳で、むしろそういう環境の方こ
そがロックが必要なんだと思います。
　で、O_EXCL を使ってロックをかけることにしました。これなら
MS-DOS でも使えますからね。

　実際にロックの対象になっているのは履歴ファイルだけではなく
て、他にログファイルと .fd2rc とがあります。.fd2rc はカスタ
マイザが上書きすることがあるので今回新たに対象に加えました。
　O_EXCL でロックするということはロックファイルが作成されて
しまう訳で、異常終了時にロックがかかりっ放しになるとか、dead
lock に陥るとかいった危険性もあるのですが、その点も可能な限
り気を遣っています。
　SIGSEGV 以外の捕捉可能な割込み終了時にはロックファイルを削
除していますし、デッドロックを回避するために一度に複数のロッ
クをするケースがないように配慮しています。

　あと、Cygwin という厄介な存在がありまして、こいつはロック
したまま rename() や unlink() 出来ないので、実は transaction
に問題があります。
　普通に open() して close() する分には大丈夫なのですが、古
いファイルを更新する際に、古いのを読みつつ新しいのを書くとい
う処理をすると最後に rename() が必要になります。
　UNIX file system だと先に rename() してから close() するこ
とにより、ロックがかかったままの状態で安全に rename() 出来る
のですが、Windows file system ではこれが出来ません。
　このため、先に close() してロックが外れたところで rename()
します。この二つの動作を atomic に実行出来ないため、タイミン
グによっては何か支障が発生するかも知れません。
　まぁ Cygwin を multi user で使うことは殆どないとは思います
が、利用する方は気をつけて下さい。


> 	非 ANSI 環境でコンパイルに失敗する点を修正。

　[FDclone-users:00533] で報告のあった bug の修正です。紆余
曲折あってご迷惑おかけしました。


> 	Cygwin 1.5.21 対応。

　CVS を追ってみると判ると思いますが、Cygwin の dirent 構造
体の実装って本当に頻繁にコロコロと変更してくれるので、もうこ
れ以上追随し切れなくなってきています。
　元々 d_reclen が無いという全然 portability を無視した設計
だったんですが、ここ数カ月の変更を見ていると d_name 以外の要
素は一切必要ないと考えているようですね。
　もうこれ以上変更されてもつき合い切れないので、「d_name 以
外の領域」をこっちで勝手に割り振って使うことにしました。

　もう、Cygwin 対応なんかしなかったら良かったかも。


> 	IGNORECASE=1 時に日本語ファイル名ソートがおかしかった点を修正。

　IGNORECASE を指定した時には大文字小文字を無視してファイル
名比較を行なうというのが仕様です。
　この時、alphabet 以外は IGNORECASE 未指定時と同様に比較さ
れるべきなのですが、ファイル名の構成文字を signed char とし
て比較していたため、日本語ファイル名が負数扱いになっていまし
た。
　このため、日本語ファイル名は英数ファイル名よりも小さな並び
順になってしまっていただけでなく、日本語ファイル名同士の順序
は逆転してしまっていました。


> 	UNICODE テーブルが壊れていた点を修正。(MS-DOS 版)

　多分 2.05 での embug だと思うんですが、MS-DOS 版は扱いがど
うもおざなりになっていまして、これまで全然気づいていませんで
した。
　MS-DOS は 16bits 環境なので、int の定義域が -32768〜32767
になります。一方 UCS2 の定義域はこの範囲を越えていて、int で
は表し切れません。
　ところが、UNICODE テーブルをソートする際に UCS2 値の比較結
果を int で受けてたので、比較する UCS2 値によっては正しい大
小関係にならないんですね。
　その結果、UNICODE テーブルが正しくソートされない状態となり、
binary search に失敗してしまっていました。

　更に 2.08c からはテーブルサイズまで int で cast してしまっ
ていたので、本来のテーブルよりかなり小さい UNICODE テーブル
が生成されてしまっていました。
　UNICODE テーブルのエントリ数は 9206 個で int の定義域に収
まっているのですが、一つのエントリに付き UCS2 と ShiftJIS と
で 4bytes 使うので、全部で 36824 bytes になります。
　これは 16bits int では負数なので、一つもエントリの無いテー
ブルになってしまっていたのです。

　結構長い間、どこからも報告が来なかったのですが、MS-DOS 版
ではフロッピードライブの日本語ファイル名くらいでしか UNICODE
を使用しないので、まず使われることがなかったんでしょう。
　当然、他の 16bits 環境でも同じことが起こっていた筈ですが、
UNIX では流石にそういう環境は現存していないでしょうから、こ
の障害は MS-DOS 版のみだと思われます。

　実は、他にも幾つか 16bits 環境固有の桁溢れが起きてたので修
正してあるんですが、まだ見つかっていない桁溢れがあるかも知れ
ませんね。
　例えば、組込みコマンド dir では日付順ソートが正しい並びに
なっていませんでした。2.04 でアクセス時刻ソートは修正してい
るんですが、修正時刻ソートは何故か放ったらかしでした。

                                               しらい たかし