--pgp-sign-Multipart_Thu_Jan_22_21:35:47_2009-1
Content-Type: text/plain; charset=ISO-2022-JP

At Thu, 22 Jan 2009 20:22:13 +0900,
Tanaka Akira wrote:
> In article <86ocxz20uy.knu / iDaemons.org>,
>   "Akinori MUSHA" <knu / iDaemons.org> writes:
>
> > でっちあげれば、たとえば…
> >
> > - NFS等で共有された領域にホストローカルなファイルを指すsymlinkを
> >   作り、別のホストではデッドリンクなんだけれども、なければ作る、
> >   という挙動に期待して各ホストでのリンク先の生成の手間をけちる
> >
> > - 新規生成ファイルのパス名がハードコードされた外部コマンドを呼び
> >   出す際に、symlinkを置いておいて別の場所に書き出されるよう細工
> >   する
> >
> > のようなケースが想定可能でしょうか。
>
> うぅむ。そういうケースって単に open するだけで、realdirpath
> を使うという話じゃないですよね。
>
> > はい、そう思います。たとえば ENOENT でエラーにするのも一つの方針
> > ではあります。
> >
> >  まれなケースなので固執はしませんが、先の例の link を creat(2)
> > ないし O_CREAT 付きで open(2) すれば dir/file にファイルができる
> > というのは事実で、 realdirpath でわざわざsymlinkを意識した処理を
> > するからにはそれを織り込みたい場合もあるはずだとは思います。

 実際にあった例では、パス名を生成する段階で

    # copy src to dst
    srcpath = Pathname(src).realpath

    dstpath = Pathname(dst)
    if dstpath.exist?
      dstpath = dstpath.realpath
    else
      dstpath = dstpath.dirname.realpath + dstpath.basename
    end

と存在チェック(の記述)が必要で、実際に処理を行うときにもまた

    if dstpath.exist?
      # differential copy
    else
      # full copy
    end

とする必要があるのが冗長に感じました。さらに、

    if srcpath.dirname.dev != dstpath.dirname.dev
      # cross-device copy
      ...
    end

というテストが実際には先の理由から正しくないということがあり、
結局欲しいのは4.4BSDの realpath(3) じゃないか、というのが動機
でした。

 上記のような例がよくあるのかどうかと言われると何とも言えない
ですが、(まだ)存在しないパスを扱うことはそれなりにあると思い
ます。


 もしかすると、 Pathname#realpath が省略可能のブロックを受け
付けるようにして、

    path.realpath { |resolved, unresolved|
      unresolved.to_s.include?("/") ? raise ENOTDIR : resolved + unresolved
    }

みたいなハンドラを書けるといいのかな。そうすると rsync のように
まだ存在しないディレクトリを生成したりする処理を書きやすくなる
かも。(.to_s.include?("/") というのがいまいちですが)

> まだまじめに考えていませんが Apache で PUT で <Directory> と
> いうのをちょっと思いついたんですが、どうかなぁ。

 ここはちょっと意味が分かりませんでした。

--
Akinori MUSHA / http://akinori.org/

--pgp-sign-Multipart_Thu_Jan_22_21:35:47_2009-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEABECAAYFAkl4aCMACgkQkgvvx5/Z4e5ZigCfcrF3YLAVOYWAZcmnaU3DItay
cVAAoLNuFcNmkhVEjzDSKxVU0rW3MoQg
=X1cb
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Jan_22_21:35:47_2009-1--