[JM:00955] coreutils.info のチェック (第 12 - 14 章)

Back to archive index

長南洋一 cyoic****@maple*****
2013年 10月 23日 (水) 21:52:42 JST


長南です。

今回は二つほど大物があるので、それは後回しにして、単純な質問から。

13.4 `touch'

     ... Fourth, the operating system primitives used to update timestamps 
     may employ yet a different resolution.

     ... and the operating system might use nanosecond resolution for 
     the current time and microsecond resolution for the primitive that 
     `touch' uses to set a file's timestamp to an arbitrary value.

  こういう primitive は「基本データ型」と訳しておけばよいのですか。 
  最初は、研究社リーダーズ+プラスに「【数】原始関数、基関数」とあった
  ので「基本的な関数」のことかと思い、「基本関数」と訳しました。
  ところが、最近 Web で調べたら、e-Words に「... ITの分野では、
  複雑な構造を形作る際の構成要素として使われる、単純あるいは基本的な
  構造のことを意味する。... プログラミングの分野では、プログラミング
  言語の仕様に用意されている最も基本的なデータ型のことを「プリミティブ型」
  (primitive type)という。... 文字型や整数型、浮動小数点数型 ...」と
  出ていたので、取りあえず直しておきました。Web によれば、「基本命令」
  (コンピュータ用語辞典、日外アソシエーツ)、「基関数」(JST科学技術用語
  日英対訳辞書、科学技術振興機構) なんて訳もあります。データ型なのか、
  関数なのか、それとも別のものなのか、何なんでしょう。

  念のため、このパラグラフの全文と訳文を載せておきます。

        The `touch' command sets the file's timestamp to the greatest
     representable value that is not greater than the requested time.  This
     can differ from the requested time for several reasons.  First, the
     requested time may have a higher resolution than supported.  Second, a
     file system may use different resolutions for different types of times.
     Third, file timestamps may use a different resolution than operating
     system timestamps.  Fourth, the operating system primitives used to
     update timestamps may employ yet a different resolution.  For example,
     in theory a file system might use 10-microsecond resolution for access
     time and 100-nanosecond resolution for modification time, and the
     operating system might use nanosecond resolution for the current time
     and microsecond resolution for the primitive that `touch' uses to set a
     file's timestamp to an arbitrary value.

        `touch' コマンドは、ファイルのタイムスタンプを、ユーザが指定した
     日時よりも精度が高くならない範囲で、表現できる最大の値にセットする。
     この値がユーザが指定した日時と違うことがあるが、それには、いくつかの
     理由がある。第一に、ユーザが指定した日時が、サポートされている精度を
     越えていることがある。第二に、ファイルシステムが、日時のタイプに
     よって別の精度を使っていることがある。第三に、ファイルのタイム
     スタンプが、オペレーティングシステムのタイムスタンプとは別の精度を
     使っていることがある。第四に、オペレーティングシステムでタイム
     スタンプの更新に使用されている基本データ型が、さらに違う精度を採用
     していることがある。そんなわけで、理屈の上では、たとえば、ファイル
     システムでは、アクセス日時には 10 マイクロ秒の精度を、更新日時には 100
     ナノ秒の精度を使用し、オペレーティングシステムの方では、現在の
     時刻にはナノ秒の精度を、`touch' がファイルのタイムスタンプを任意の
     値に設定するために使う基本データ型には、マイクロ秒の精度を使用して
     いる、そういうこともありえるのである。

14.1 `df'

     ... GNU `df' does not attempt to determine the disk usage on
     unmounted file systems, because on most kinds of systems doing so
     requires extremely nonportable intimate knowledge of file system
     structures.

     ... また、GNU の `df' は、マウントされていない
     ファイルシステムのディスク使用量を測定しようとはしない。なぜなら、
     ほとんどのシステムにおいて、そういうことを行うには、ファイルシステム
     の構造について他と全く共通性のない内奥の知識が必要だからである。

  "on most kinds of systems" の systems は、オペーレーティングシステム
  ですか、それとも、ファイルシステム?

14.3 `stat'

     ... When discarding excess precision, time stamps are truncated 
     toward minus infinity.

     ... なお、余分な精度を捨てる際、タイムスタンプは負の無限大方向に
     切り下げられる (訳注: 日常の言葉で言うと、タイムスタンプのような
     正の数値の場合、指定された桁数より下の部分は切り捨てられると
     いうこと。以下の例を参照)。

  「負の無限大方向に切り下げる」というのは、わたしとしては初めて出会う
  言葉でした。それで、訳注をつけておいたのですが、こういう意味に取って
  よいのでしょうか。「以下の例」というのは、次のようなものです 
  (コメントは小生)。

     精度指定:
       $ stat -c '[%.3Y]' /usr    # Epoch からの秒数で表した mtime。
       [1288929712.114]           # 小数点以下 3 桁まで
       $ stat -c '[%.Y]' /usr     # 同上。小数点以下 9 桁まで
       [1288929712.114951834]

さて、大物です。

12.2 `ln'

  用例の後ろ二つが、どう訳したらよいのか分かりません。こういうものです。

     Bad Example:

     # Hard coded file names don't move well.
     ln -s $(pwd)/a /some/dir/

     Better Example:

     # Relative file names survive directory moves and also
     # work across networked file systems.
     ln -s afile anotherfile
     ln -s ../adir/afile yetanotherfile

  一応、こんなふうに訳しました。意訳というよりは、作文です。

     悪い例:

     # 絶対パスによるリンク対象の指定は、リンク対象の位置が変わると、
     # 役に立たない。
     ln -s $(pwd)/a /some/dir/

     よりよい例:

     # 相対パスによるリンク対象の指定は、リンクやその対象を含む
     # ディレクトリが移動しても、両者の相対的な位置関係が変わらない
     # かぎり、問題がない。また、ネットワークでつながったファイル
     # システム間でも通用する。
     ln -s afile anotherfile
     ln -s ../adir/afile yetanotherfile

  まず、"Bad Example/Better Example" というのが腑に落ちません。
  リンク対象の指定に相対パスを使うか、絶対パスを使うかは、どちらが
  よいというものではないはずです。この ln の info の本文でも「There 
  are trade-offs to using absolute or relative symlinks. (シムリンクの
  作成に絶対パスを使うか、相対パスを使うかには、それぞれ一長一短がある)」
  と書いています。 絶対パスによるシムリンクを Bat Example と言ってしまう
  のは、どういうものなのか ...

  第二に、Better Example の方の "Relative file names survive directory 
  moves" は、不正確だと思います。リンク対象のファイルだけ別のディレクトリ
  に移動すれば、たいていリンク切れになりますし、リンクファイルだけ移動
  した場合も、リンク切れになる可能性があります。それで、リンク切れに
  ならない条件を作文して補足したのですが、わたしが何か勘違いをしている
  のでしょうか。あるいは、もっと原文に近い素直な訳し方がないものでしょうか。

14.3 `stat'

     The mount point printed by `%m' is similar to that output by `df',
     except that:
        ---- (少し省略) ----
     * stat outputs the alias for a bind mounted file, rather than the
       initial mount point of its backing device.  One can recursively
       call stat until there is no change in output, to get the current
       base mount point

     `%m' によって表示されるマウントポイントは、`df' によるマウント 
     ポイントの出力とほぼ同じである。ただし、以下の点が違う。
        ---- (省略) ----
     * bind マウントされているファイルについては、stat はそのファイルが
       載っているデバイスの最初のマウントポイントではなく、bind マウントで
       指定された別名 (訳注: 原文は alias。`mount --bind olddir newdir'
       における newdir のことか) の方を出力する。出力に変化がなくなる
       まで、再帰的に stat を呼び出せば、現在ベースになっているマウント
       ポイントを知ることができる。

  これが、わたしにはさっぱりわかりません。"the alias for a bind mounted 
  file" や "the current base mount point" は、どう解すればよいので
  しょうか。

  linux-3.x と stat-8.20 の組み合わせの場合、"stat -c "%m FILE" は、
  bind マウントでは、`mount --bind olddir newdir' で言えば、newdir を
  出力します。そこで、alias は newdir と取っておきました。ついでに言うと、
  "its backing device" の backing も、よくわかりません。

  しかし、"the current base mount point" の方は、「デバイスを最初に
  マウントしたマウントポイント」と考えても、「結局 newdir のこと」と
  考えても、linux-3.2 (3.4 でも) と coreutils-8.20 (8.17 や 8.21 でも) 
  の組み合わせでは、実際の動作と矛盾してしまいます。stat を再帰的に
  呼び出しても、最初のマウントポイントは出力されません。また、newdir 
  なら、再帰的に呼び出す必要がありません。それで、以下のような訳注を
  付けておきましたが、ゴタゴタしている上に正しいかどうか分かりません。

     (訳注: 訳者には意味不明。「現在ベースになっているマウントポイント
     (the current base mount point)」が、上記訳注の newdir のことなら、
     statを再帰的に呼び出すまでもない。`stat -c "%m" newdir/FILE' は、
     newdir を表示する。また the current base mount point が「根底にある 
     (すなわち、デバイスを最初にマウントした) マウントポイント」のこと
     なら、stat を再帰的に呼び出しても、それを突き止めることはできない。
     ひょっとすると、書式指定子に '%m' が追加された最近の stat を 
     linux-2.6 の古いカーネルと組み合わせて使ったときの動作を言っている
     のかもしれない。その場合は、`stat -c "%m" newdir/FILE' は上記の 
     olddir を出力する。その結果、stat を再帰的に実行することで、最初に
     デバイスをマウントしたときのマウントポイントを知ることができる)。

  上記の訳注は、わたしが実験してみた結果です。stat を再帰的に呼び出すには、
  次のようなスクリプトを使いました。再帰という考え方は苦手なのですが、
  これで stat の再帰呼び出しになっているでしょうか。

    $ cat seek_mp.sh
    #!/bin/sh

    cmd="stat のパス"    # debian squeeze (linux-2.6、coreutils-8.5) で
                         # coreutils-8.20 の stat を使用するため
    find_mp () {
            mp=$( $cmd -c "%m" $1 ) 
            echo $mp

            if [ "$1" = "$mp" ]
            then
                    echo "the base is $mp."
                    exit
            fi

            find_mp $mp
    }
    find_mp $1

  stat やカーネルがバージョンアップする間に、動作が変わってしまったのでは
  ないかという気もします (%m が追加されたのは、多分 version 8.6)。
  ubuntu-13.10 や redhat 系ではどういう動作になるのでしょう。使用して
  いる方がいらっしゃったら、カーネルと stat のバージョン、及び動作を
  知らせていただけると、幸です。

-- 
長南洋一




linuxjm-discuss メーリングリストの案内
Back to archive index