[FDclone-users:00649] Re: FDclone 2.09a has been released

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

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

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

　Mac OS X の件にかまけている間に bug fix がたんまり溜ってし
まいましたので、Mac OS X 問題は取り敢えず後廻しにさせて貰っ
て、それ以外の bug fix 分を release します。

> 　以下は HISTORY より今回の変更点の抜粋です。

　結構沢山あるのですが、以下、丁寧な解説を頑張ってみましょう。


> 	GNU tar のハードリンクされたアーカイブファイルに対応。

　GNU tar では、hard link されたファイルが実体と共に格納され
る場合、実体は一方のみ格納して他方はリンク情報のみ格納されま
す。
　この時、一覧表示をさせると、実体を伴わない方のファイル名部
分には「foo link to bar」の文字列が表示されます。
　FDclone ではこの「link to」を含む全体をファイル名として認
識してしまうのですが、特に「bar」の部分が「/」を含んでいると
directory として認識してしまうので判りにくい表示になっていま
した。
　そこで、「link to」を含むファイル名は hard link を意味する
文字列として認識させることとして、GNU tar の hard link に対
応しています。
　そのせいで、本当に「link to」を含むファイル名を格納した場
合にも hard link だと思い込んでしまいますが、実害は殆んど無
さそうなので、このケースの対処はしていません。

　また、hard link もしくは symbolic link を単体で展開した場
合、実体が存在しないので内容を参照出来ないという状況でしたが、
これらのケースでは実体も同時に展開するようにしました。
　このため、archive 内の link ファイルも普通に参照出来るよう
になっています。


> 	ファイルロック時にタイムアウトを設定。

　FDclone では fcntl lock 以外に O_EXCL を使ったロック機構を
用意してファイルを保護していますが、どちらの実装もタイムアウ
トを設けていませんでした。
　このため、別プロセスがファイルをロックしたまま長いこと止ま
ったままになっていると、FDclone は延々と待ち続けるしかなく、
それがフリーズしたように見えてしまっていました。
　この対応として約 3 秒の間にロックが解放されなかった場合に
は、その旨の表示を行なった上で、そのファイルの使用を諦めて中
断する実装に改めました。
　もしくは、cc_intr (一般的には Ctrl+C) キーの入力により、強
制的にロックを中断させることが出来るようにもなっています。


> 	Cygwin で共有フォルダを扱えなかった点を修正。

　[FDclone-users:00621] で軽く触れている支障に対する対処です。
Cygwin だけでなく実は MS-DOS 版でも一部対処しています。

　「//」で始まるパス名が hostname を含む network 上のパスを
表すというルールは POSIX でも許容されている表記なのですが、
実際に Cygein の system call レベルで実装されているとは知り
ませんでした。
　特に Cygwin では「//」で始まるパス名に対して chdir() 出来
てしまうので、CWD が「//」で始まる状態で FDclone を起動する
と CWD を見つけられずに「/」に移動していました。
　FDclone では複数連続する「/」は強制的に一個にしてしまって
いたので、先頭の二個だけは保持するようにして、「//」に対応し
ています。

　但し、hostname を後続しない「//」には移動も参照も出来ない
ようにしてあります。「//」だけだと「/」と同値と見なされるの
で、後ろに hostname を付けて「//host」形式で使って下さい。
　Cygwin では「//」に対して opendir() したり chdir() したり
出来るのですが、それが出来ない Windows API の挙動に合わせて
「//」は無効にしました。
　というのも、そこそこ大きな LAN で複数のファイルサーバが存
在する場合、「//」の中を一通り fetch するのに何分もかかって
しまって実用的ではないからです。
　実際、Cygwin の command line から「ls -la //」を実行してみ
ると、フリーズしたかのように応答が遅くなってしまうことを確認
出来ると思います。
　この危険性を承知の上で、敢えてこの制限を取り払いたい場合は、
pathname.c: isdslash() にある「|| defined (CYGWIN)」という記
述部分を削除すると、「//」を有効なパス名として扱えるようにな
ります。

　因みに、Windows API の場合は、OpenFile() や FindFirst() は
「//」で始まるパス名に対応しているんですが、chDir() が対応し
ていないために余り実用的には使えないと思います。
　多分出来ることと言えばファイルコピーと内部コマンドの「dir」
くらいかと。


> 	幾つかの漢字コード設定で UTF8-mac が効かなかった点を修正。

　[FDclone-users:00637] で私自身が報告している一件です。具体
的には INPUTKCODE と PTYOUTKCODE とで UTF8-mac の NF 対応が
未実装でした。

　PTYOUTKCODE は PTYMODE=1 の時に疑似端末側から出力される漢
字コードの指定で、これを UTF8-mac にすれば NF された濁点仮名
も合字形式で LANGUAGE の漢字コードに変換されるようにしました。
　NF された濁点仮名は一文字目として普通の濁点なし仮名が来る
ので、先読みしないと濁点の有無が判断出来ないんですよね。その
ために buffering するようにしたので多少遅くなります。

　同様のことが疑似端末への入力側にも言えるのですが、こちらで
は INPUTKCODE から PTYINKCODE への変換になります。INPUTKCODE
が UTF8-mac の時には同様に先読みして NF 対応しました。
　また、INPUYKCODE は PTYMODE=0 の時の普通の文字列入力時にも
効いて来るので、こちらも同様に先読みをして NF 対応しています。

　勿論、NF される合字は漢字だけではないので、ウムラウト等に
も対応出来ている筈ですが、濁点仮名以外の合成文字は JIS 漢字
の中には存在しないので、UTF8-mac -> UTF8 という変換以外では
実質濁点仮名だけの対応になると思います。


> 	PTYMODE=1 時に日本語入力の文字化けが起こることがある点を修正。

　これは上記の UTF8-mac の NF 対応をいている時に見つけた bug
です。
　キー入力された multibyte 文字を疑似端末側に送信する途中で
割込み処理が入ると multibyte 文字が分断されてしまっていたの
で、これも buffering を行ない漢字はまとめて送信するようにし
ました。


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

　何故か IGNORECASE=1 にしても「A」より「a」が大きくなる実装
になっていました。MS-DOS 版では常に IGNORECASE=1 状態なので、
もっと早く気づいても良さそうなものなんですけどね。


> 	一部端末環境でファンクションキーが効かなかった点を修正。

　[FDclone-users:00623] で報告のあった bug を修正しました。

                                               しらい たかし