どのシステムで// foo / barは/ foo / barと異なるのですか？

POSIX仕様の全体にわたって、規定（があります1、2、3の実装は、2から始まるパスを治療することを可能にする...）/特別。

POSIXアプリケーション（すべてのPOSIX準拠システムに移植できるようにPOSIX仕様に記述されたアプリケーション）//foo/barは、それが同じであると想定することはできません/foo/bar（ただし///foo/bar、同じであると想定できます/foo/bar）。

今、//foo特別に扱うそれらのPOSIXシステム（歴史的で、まだ維持されている）は何ですか？私はPOSIXの提供がMicrosoftによってUnixバリアント（XENIX）とWindows POSIXレイヤー（おそらく誰でも確認できますか？）のためにプッシュされたと信じました（今では間違っていることが証明されました）。

これは、Microsoft WindowsのPOSIXのようなレイヤーでもあるCygwinによって使用されます。Microsoft Windows以外のシステムはありますか？OpenVMS？

//foo/bar特別なシステムでは、何に使用されますか？//host/pathネットワークファイルシステムにアクセスするには？仮想ファイルシステム？

Unixライクで実行される一部のアプリケーションは（システムのAPI //foo/barではない場合）、パスを特別に処理しますか（そうでなければ/foo/bar、ファイルシステム上のパスとして処理するコンテキストで）。

編集、それから私は//foo/bar仕様の取り扱いの起源についてオースティングループのメーリングリストで質問しました、そして議論は興味深い読み物です（少なくとも考古学の観点から）。

これは、これまでに与えられた回答の編集と索引です。この投稿はコミュニティWikiであり、100以上の評判を持つ誰でも編集でき、誰からも評判を得ることはできません。自由にあなた自身の答えを投稿し、ここにリンクを追加してください（または私がそれをするのを待ってください）。理想的には、この回答は要約である必要があります（短いエントリで、他の個々の回答には詳細が含まれます）。

現在アクティブに維持されているシステム：

• Cygwinの。Microsoft Windows用のPOSIXレイヤー。Windows UNCパスに使用されます。
• 1.3以降の UWIN。Windows用の別のPOSIXレイヤー。少なくとも//host/fileネットワークファイル共有パスに使用されます。
• ^{@OlivierDulac} IBMのz / OSのよう POSIXのバグトラッカーで述べた、 z / OSは解決//pathnameMVSデータセットへの要求をファイルをネットワークにありません、。例。

機能停止システム

• ^@BinaryZebra Apollo Domain / OS（確認済み）。また、に言及した公式説明UNC（汎用名前付け規則）できるだけの起源//host/path表記（も参照、ページ2-15）を。

  Donn Terryによると、Domain / OSのPOSIX仕様にその規定を含めることを推進したのはHP（Apollo Computersを買収した）でした。

• ^@jillagre テクトロニクスUTEK（裏付け）//host/pathのパスである分散ファイルシステム。

• ^@gilles QNX 4 FLEET分散処理システムであるノード123に（言及 QNX 6ドキュメントに）。//123/path/path
• ^@roaima AT＆T SysVリリース3（未検証）。//host/pathin（SVR4で廃止） RFSリモートファイル共有システム。
• ^@Scott SEL / Gould UTX-32（未検証）。に使用され//host/pathます。

//foo/barパスを特別に扱うアプリケーション

• ^@Prem PERFORCEはここ//depot/A/B/C/Dでパスを指すデポ。
• ^@WChargin Blender。その構成では、（データブロックに関連付けられたブレンドへの）相対パスにプレフィックスを使用し//ます。

Unixライクで実行される一部のアプリケーション（システムのAPIではない場合）は、// foo / barパスを特別に処理しますか？

//depot/A/B/C/Dパスを使用してデポを参照するPerforceを認識しています。//Client/C/Dクライアントがを指して//depot/A/B/いる場合、Perforceはパスもサポートします。ここでは、ローカルファイルシステムにこれらのパスがない場合があります。

p4 filelog //depot/A/B/C/Dfileがなくても、そのファイルの履歴が表示されます/depot/A/B/C/D。

p4 filelog C/D 適切なディレクトリから実行された場合、そのファイルの履歴も表示されます。

参照：https : //www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

数十年前、Tektronix Utek（BSD 4.2ベースのUnix、最初にNational Semiconductors 32016 CPU、次にMotorola 68020に搭載）はDFS（分散ファイルシステム）と呼ばれるものを提供//foo/barし、その下でdfsサーバー/bar上のファイルを参照していましたfoo。その後、SunのNFSによって廃止されました。

残念ながら、私はまだそれを裏付けることを参照していませんが、最終的に私のセラーでいくつかのUtekのドキュメントを見つけて、この返信を更新するかもしれません。

この答えからのリードに従って。また、Bitsaversのマニュアルの 2-15ページを読んでください（^@grawityに感謝）。

共有データ
Domain / OS分散ファイルシステムの2番目の設計原則（デフォルトで共有）は、グローバルな統一ネームスペースを意味します。分散ファイルシステムの名前空間は、巨大なタイムシェアリングファイルシステムの名前のようにユーザーに表示されます。これは、絶対パス名がネットワークルートの名前（//と呼ばれる）で始まることができることを除いて、従来のUNIX階層名前空間です。ローカルノードのルート（/ディレクトリ）に相対するパス名を表現することもできます。

「最初の印刷：1985年7月」の古いマニュアルもあります。1-4ページ：

図1-2の二重スラッシュ（//）は、ネーミングツリーの最上位レベルであるネットワークルートディレクトリを表します。

したがって、ApolloのDomain / OS //がネットワークルートに使用されたことを確認できます。

別のアプリケーション：Blenderは、リード//をプロジェクトディレクトリ（.blendファイルが保存されているディレクトリ）への参照として扱います。関連するマニュアルページはこちらです。

これは、Unix以外のオペレーティングシステム（Windowsなど）にも当てはまります。

ReactOSプロジェクト- NTカーネルと関連APIの自由とオープンソース実装です-明らかに、独自の実装に着手したのInterix様POSIXサブシステムをMS独自のOS / 2サブシステムもされているが（文脈で言及した、全く言及しませんReactOSアナログで作られています）。

努力は、これまでしてきたが、小さな、fork()明らかに現実です。未解決の問題にリストされているサブシステムのプロジェクトページからの抜粋を以下に示します。

パス

POSIXアプリケーションでWin32パスを使用する最良の方法は何ですか？アイデア：

• 変換//<device>/<path> \\.\<device>\<path> （ドライブ文字の特別な場合- //<letter>/<path>=> <letter>:\<path>-および特別なエスケープ//./<raw text>=>で\\.\<raw text>UNCパスを指定できます//unc/<path>）。//パスは実装固有の動作のために標準で予約されており、//<letter>/Win32パスをエスケープする構文は既存のPOSIX互換環境で広く使用されています

• 「裸の」Win32パスを認識するためのヒューリスティック

• Win32パスおよび//パスの大文字と小文字を区別しない検索（標準では、この種の実装固有の//パスの動作が許可されていますか？）。

どれだけ実装されているのかわからないので、それがどのように適格であるかは分かりませんが、問題の有用な興味深い説明だと思いました。

1980年代、SEL / GouldにはUTX-32と呼ばれるUnixオペレーティングシステムがあり、Solaris と同等 でした。すなわち、host上のリモートアクセスパス。私はそれに関するドキュメントを見つけることができないので、これがRFSであったか並列進化であったか（またはAT＆T//host/path/net/host/pathpathhostストール グールドから取得しました）。

//host/pathAT＆T SysV.3では、RFSリモートファイル共有の実装の一部として表記法が使用されていたという漠然とした記憶があります。これは、SysV.4がリリースされた頃に最終的に放棄され、Sun Microsystemsのよりシンプルで人気のあるNFSが採用されました。

ただし、構文への具体的な参照は見つかりません。今レビューしたドキュメントでは、ユーザーがリモートホスト名を明示的に指定するという考え方は、場所の独立性の設計原則に反していたことを示しているようです。

参考資料1. RFSアーキテクチャの概要

POSIXは、A.4.12パス名解決パラグラフ9および10 の根拠に次のように述べています。

一部のネットワークシステムでは、/ .. / hostname /構造が別のホストのルートディレクトリを参照するために使用され、POSIX.1はこの動作を許可します。

他のネットワークシステムでは、同じ目的で//ホスト名を使用します。つまり、二重の最初のスラッシュが使用されます。

これは、//「ネットワークルート」を意味すること、または少なくともそれがPOSIXに含まれていたときのアイデアであったことを確認しているようです。

開始されたパス名のパスの//途中にある意味を削除するための規則が続き/ます。

... 2つ以上の<slash>文字の非先頭シーケンスが
単一の<slash>として扱われるため、...

もちろん、//開始されたパス名は//、（開始時ではなく）パス名内の使用を拡張または変更する場合があります。POSIX.1ではこれが可能です。これは最後//に、パス名の先頭にのみ許可されていることを確認します。