На яких системах // foo / bar відрізняється від / foo / bar?

Протягом специфікації POSIX існує положення ( 1 , 2 , 3 ...), що дозволяє реалізаціям обробляти шлях, починаючи з двох /спеціально.

Програма POSIX (додаток, написаний у специфікації POSIX для перенесення у всі системи, сумісні з POSIX) не може вважати, що //foo/barце те саме, що /foo/bar(хоча вони можуть вважати, що ///foo/barце те саме /foo/bar).

Тепер, що таке системи POSIX (історичні та досі підтримувані), які стосуються //fooспеціально? Я вважав (зараз я був неправомірним ), що положення POSIX було підштовхнуто Microsoft для їх варіанту Unix (XENIX) і, можливо, шару Windows POSIX (хто-небудь може це підтвердити?).

Він використовується Cygwin, який також є POSIX-подібним шаром для Microsoft Windows. Чи є які-небудь системи Windows Windows? OpenVMS?

Для систем, де //foo/barє особливим, для чого він використовується? //host/pathдля доступу до мережевих файлових систем? Віртуальні файлові системи?

Чи застосовують деякі програми, що працюють на Unix-подібних (якщо це не API системи), //foo/barспеціально обробляти контури (у контекстах, де вони інакше трактуються /foo/barяк шлях до файлової системи)?

Редагувати , я з тих пір задав запитання в списку розсилки австинських груп про походження //foo/barобробки в специфікації, і обговорення цікаве прочитання (принаймні з точки зору археології).

Це компіляція та покажчик відповідей, наданих до цього часу. Ця публікація - це вікі спільноти , її може редагувати будь-хто зі 100+ репутацією, і ніхто не отримує від неї репутації. Сміливо опублікуйте свою відповідь і додайте посилання на неї сюди (або зачекайте, коли я це зроблю). В ідеалі ця відповідь має бути просто підсумком (з короткими записами, тоді як окремі відповіді містять деталі).

В даний час активно підтримуються системи:

• Сігвін . Рівень POSIX для Microsoft Windows. Використовується для шляхів Windows UNC .
• UWIN з 1.3. Ще один шар POSIX для Windows. Принаймні використовується для//host/fileмережевих шляхів обміну файлами.
• ^{@OlivierDulac} IBM z / OS, як згадується в трекері помилок POSIX , z / OS вирішує //pathnameзапити до наборів даних MVS , а не до мережевих файлів. Приклад .

Неіснуючі системи

• ^@BinaryZebra Apollo Domain / OS (підтверджено). Також згадується в Офіційному описі UNC (Універсальна конвенція про найменування) як можливе походження //host/pathпозначень ( див. Також , стор. 2-15).

  За словами Донна Террі , саме HP (який придбав Apollo Computers) підштовхнуло до включення цього положення в специфікацію POSIX для Domain / OS.

• ^@jillagre Tektronix Utek ( підтверджений ), де//host/pathє шлях до розподіленої файлової системи .

• ^@gilles QNX 4 з розподіленою системою обробки FLEET, дезнаходитьсяна вузлі 123. (згадується в документації на QNX 6. )//123/path/path
• ^@roaima AT&T SysV, випуск 3 (неперевірений). //host/pathв (припинено в SVR4)Система віддаленого обміну файлами RFS .
• ^@Scott SEL / Gould UTX-32 (неперевірений). Використовується для//host/path.

Програми, які розглядаються //foo/barспеціально для доріжок

• ^{@ Perrem} Perforce, де//depot/A/B/C/Dйдеться про шлях у депо .
• ^@WChargin Blender . У його конфігурації ви використовуєте //префікс відносних шляхів (до суміші, пов'язаної з блоком даних) .

Чи застосовують деякі програми, що працюють на Unix-лайках (якщо це не API системи), // foo / bar Paths?

Мені відомо, що Perforce використовує //depot/A/B/C/DШляхи для посилання на депо. Perforce також підтримує //Client/C/DШляхи, коли Клієнт вказує на //depot/A/B/. Тут локальна FileSystem може не мати цих Шляхів.

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

Кілька десятиліть тому Tektronix Utek (Unix на базі BSD 4.2, спочатку на процесорах National Semiconductors 32016, потім Motorola 68020 s) забезпечував щось, що називається DFS (розподілена файлова система), під яким //foo/barпосилався на /barфайл на fooсервері dfs. Пізніше він був застарілий NFS Sun.

На жаль, я ще не посилаюся на це, але, можливо, я, можливо, знайду документацію Utek у своєму підвалі та оновлюю цю відповідь.

Слідом за результатами цієї відповіді . І читати сторінку 2-15 із посібника від Bitsavers (спасибі ^@grawity ).

Спільні дані
Другий принцип дизайну розподіленої файлової системи Домен / ОС, спільний доступ за замовчуванням, передбачає глобальний єдиний простір імен. Простір імен розподіленої файлової системи видається таким користувачам, як гігантська файлова система тимчасового обміну. Це традиційний ієрархічний простір імен UNIX, за винятком того, що абсолютні назви шляхів можуть починатися з імені мережевого кореня (званий //). Можна також висловити імена шляхів відносно кореня локального вузла (каталогу /).

Існує також старіший посібник з «Першої друку: липень 1985 року». На сторінці 1-4:

Подвійні косої риски (//) на рисунку 1-2 представляють верхній рівень дерева імен, мережевий кореневий каталог.

Отже, ми маємо підтвердження, що домен / ОС від Apollo використовували //для мережевого кореня.

Інша програма: Blender розглядає ведучі //як посилання на каталог проекту (каталог, в якому .blendзберігається файл). Ось відповідна сторінка керівництва .

Це справедливо і для не-Unix-подібних операційних систем (тобто Windows).

Проект ReactOS - це безкоштовна та відкрита реалізація ядра NT та пов'язаних з ним API - очевидно, взяв на себе зобов'язання також реалізувати власну підсистему POSIX, схожу на Interix (хоча оригінальна підсистема MS / OS також згадується в контексті , не згадуючи виготовлений з аналога ReactOS) .

Хоча зусилля поки що були невеликими , fork()це, мабуть, реальність. Ось уривок зі сторінки проекту підсистеми, перелічений у відкритих випусках :

стежки

Який найкращий спосіб використовувати шляхи Win32 в додатках POSIX? ідеї:

• translate //<device>/<path> into \\.\<device>\<path> (зі спеціальним регістром для букв диска - //<letter>/<path>=> <letter>:\<path>- і спеціальним escape //./<raw text>=> \\.\<raw text>. UNC-шляхи можна вказати за допомогою //unc/<path>) . //шляхи зарезервовані стандартом для поведінки, що //<letter>/залежить від впровадження, і синтаксис для виходу з шляхів Win32 широко використовується в існуючих середовищах сумісності POSIX

• евристика для визнання "голих" шляхів Win32 як такої

• нечутливий до регістру шлях та //шляхи Win32 (чи дозволяє стандарт цей тип поведінки для //шляхів?) .

Я не впевнений, як це кваліфікується, оскільки я не впевнений, наскільки це було реалізовано, але я подумав, що це корисно цікавий опис проблеми.

У 1980-х роках SEL / Gould мала операційну систему Unix під назвою UTX-32, яка була еквівалентною в Solaris; тобто шлях віддаленого доступу до хоста . Я не можу знайти жодної документації на нього, тому не знаю, чи це був RFS чи паралельна еволюція (чи AT&T)//host/path/net/host/pathpathhostвкрав придбав його у Гулда).

У мене розпливчаста пам'ять, що //host/pathпозначення використовувались на AT&T SysV.3 як частина його віддаленої реалізації файлів RFS . Це врешті-решт було відмовлено від часу виходу SysV.4 на користь простішого, але більш популярного NFS від Sun Microsystems.

Однак я не можу знайти жодних конкретних посилань на синтаксис, і документація, яку я переглянув лише зараз, схоже, вказує на те, що ідея користувача, яка явно визначає віддалене ім’я хоста, була б протистоїть принципу проектування незалежності від місця розташування.

Список літератури 1. RFS Архітектурний огляд

POSIX стану в Обґрунтування для A.4.12 PathName Резолюція Пункти 9 і 10:

У деяких мережевих системах конструкція /../hostname/ використовується для посилання на кореневий каталог іншого хоста, і POSIX.1 дозволяє цю поведінку.

Інші мережеві системи використовують конструкцію // ім'я хоста з тією ж метою; тобто використовується подвійний початковий нахил.

Це, здається, підтверджує, що //означає "мережевий корінь", або принаймні, що це було ідеєю, коли це правило було включено в POSIX.

Дотримуйтесь правил, щоб видалити будь-яке значення //посередині шляху для /розпочатого імені Pathname:

... оскільки непровідні послідовності двох або більше знаків <косої частини>
розглядаються як один <косої>, ...

Звичайно, //розпочате Pathname може розширити або змінити використання //всередині Pathname (не на початку). POSIX.1 дозволяє це. Це останнє підтверджує, що єдині //дозволені є на початку Pathname.