web-dev-qa-db-ja.com

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

POSIX仕様全体を通して、実装が2つの/で始まるパスを特別に処理できるようにするための規定( 12 、 ...)があります) 。

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

さて、//fooを特別に扱うPOSIXシステム(歴史的であり、現在も維持されている)は何ですか?私は信じました(私は 間違っていることが証明されました )。POSIXプロビジョニングはMicrosoftによってUnixバリアント(XENIX)とおそらくWindows POSIXレイヤー(だれかそれを確認できますか?).

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

//foo/barが特別なシステムでは、それは何のために使用されますか? //Host/pathはネットワークファイルシステムにアクセスしますか?仮想ファイルシステム?

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


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

116

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

現在活発に維持されているシステム:

消滅したシステム

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

92

Unixライクで実行されている一部のアプリケーション(システムのAPIでない場合)は、// foo/barパスを特別に扱いますか?

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

p4 filelog //depot/A/B/C/Dには、ファイルがない場合でも、そのファイルの履歴が表示されます/depot/A/B/C/D

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

リファレンス: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

16
Prem

数十年前、 Tektronix Utek(BSD 4.2ベースのUnix、最初はNational Semiconductors 2016 CPUs、次にMotorola 6802 s)はDFS(分散ファイルシステム)//foo/barfoo dfsサーバー上の/barファイルを参照していました。その後、SunのNFSによって廃止されました。

残念ながら、これについてはまだ言及していませんが、最終的に自分のセラーでUtekのドキュメントを見つけて、この返信を更新する可能性があります。

13
jlliagre

リードに続く この回答から 。そして、ページ2-15を Bitsaversからのマニュアル (おかげで @ grawity)。

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

また、「最初の印刷:1985年7月」を伴う 古いマニュアルfrom もあります。 1-4ページ:

図1-2の二重スラッシュ(//)は、ネーミングツリーの最上位、ネットワークルートディレクトリを表しています。

したがって、ApolloのDomain/OSが//ネットワークルート。

7
user79743

ReactOS プロジェクト-これは、NTカーネルと関連するAPIの無料でオープンソースの実装です-独自の Interix -like POSIXサブシステム(MSの元のOS/2サブシステムも コンテキストで言及されています ですが、ReactOSアナログについては言及されていません)

これまでの取り組みは small でしたが、fork()は明らかに現実のものです。これは、サブシステムのプロジェクトページからの抜粋で、未解決の問題にリストされています。

パス

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

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

  • そのような「裸の」Win32パスを認識するヒューリスティック

  • win32パスと//パスの大文字と小文字を区別しないルックアップ(この規格では、//パスのこの種の実装固有の動作を許可していますか?)

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

5
mikeserv

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

これは、Unixに似ていないオペレーティングシステム(Windowsなど)にも当てはまります。

5
wchargin

漠然とした記憶がある//Host/path表記法は、AT&T SysV.3で RFS Remote File Sharing 実装の一部として使用されていました。これは、SysV.4がリリースされた頃に廃止され、よりシンプルで人気の高い [〜#〜] nfs [〜#〜] がSun Microsystemsから提供されました。

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

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

4
roaima

1980年代の SEL/Gould にはUTX-32と呼ばれるUnixオペレーティングシステムがあり、//Host/pathはSolarisの/net/Host/pathと同等でした。つまり、リモートアクセスパスpathon HostHost。それに関するドキュメントが見つからないので、これがRFSであるのか、並行進化であるのか(またはAT&Tであるのか) ストール Gouldから取得しました)。

4
Scott

POSIXは Rationalefor A.4.12 Pathname Resolution パラグラフ9および10で述べています。

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

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

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


//で始まるパス名のパスの途中にある/の意味を削除するためのルールに従います。

...先行しない2つ以上の<slash>文字のシーケンスなので
単一の<スラッシュ>として扱われます...

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

4
user79743