[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FDclone-users:00335] Re: copying from/to a linked file



 しらいです。

In Message-Id <86hdqx34sm.knu@iDaemons.org>
        "Akinori MUSHA" <knu@iDaemons.org>さんwrites:
>  GNU cp(1) の実体一致時の処理には熟考の跡が見られますよ。
> coreutils の src/copy.c:same_file_ok() がそれですが、特に
> source が symlink で destination が実 file の場合、たとえ
> -f や --remove-destination を付けても上書きはしないように
> なっています。

 んー、それは熟考なしで定着してしまった仕様がまずあって、そ
の仕様からの継承性を維持するために改めて熟考した結果のように
見えますけど。


>  symlink でその実体を上書きするというのをユーザが意図して
> いるとは考えづらいので、伝統的な cp はもちろん、上に書いた
> ように後発で意欲的に機能拡張している GNU cp でも、コピーは
> 実行されません。

 実体の上書きが自身の link 先の削除を意味するので、そういう
ケースではそんなことを user が意図しているとは考えにくいです
ね。目的も余り思いつきませんし。
 ただ、hardlink の方について考えるならば、実体が同じものに
上書きという結果はそれなりに妥当性があるし、そういう意図も想
像の範囲内です。大した弊害もないし。


>  確認ですが、 FDclone (の次のバージョン)ではどうなりますか?
> 
>  私は、 cp と同様、実体が一致している旨を表示してコピーは
> 避けてほしいと思っています。

 現実問題としては、現行仕様の FDclone は symlink で既存 file
を上書き出来る実装になっていないと思います。symlink() の前に
unlink() がないので。
 それはそれで逆に問題ありなので、destination が link 先実体
である場合を除いては敢えて unlink() すべきかなと思っています。
実体が同じ場合は現行仕様どおりということで。

 一方の hardlink は、実際 GNU cp の --remove-destination で
も上書きして別物にしてしまう仕様なので、そういう仕様があるこ
と自体には問題ないと思います。
 FDclone では、問い合わせに対して user が敢えて「上書き」と
回答した点を重視して unlink() -> open(O_EXCL) という上書き仕
様が妥当なんじゃないかと考えています。

                                               しらい たかし