В каких системах // foo / bar отличается от / foo / bar?

Несколько десятилетий назад, Tektronix Utek (BSD 4. 2 на базе Unix, сначала на процессорах National Semiconductors 32016, затем Motorola 68020s) предоставляла нечто под названием DFS (распределенная файловая система), под которой //foo/bar ссылалась на /bar файл на foo dfs-сервере. Позже он был заменен NFS от Sun.

К сожалению, у меня пока нет ссылок, подтверждающих это, но я могу найти документацию Utek в моем подвале и обновить этот ответ.

Обрабатывают ли некоторые приложения, работающие на Unix-подобных ОС - если это не API системы - пути //foo/bar особым образом?

Я знаю о Perforce, который использует //depot/A/B/C/D пути для ссылки на хранилище. Perforce также поддерживает //Client/C/D Paths, когда клиент указывает на //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

Я смутно помню, что нотация // host / path использовалась на AT&T SysV.3 как часть его RFS Remote File Sharing реализация. В конечном итоге от этого отказались примерно в то время, когда была выпущена SysV.4, в пользу более простой, но более популярной NFS от Sun Microsystems.

Однако я не могу найти никаких конкретных ссылок на синтаксис, а документация, которую я только что рассмотрел, похоже, указывает на то, что идея о том, что пользователь явно указывает имя удаленного хоста, противоречила бы принципу проектирования независимости от местоположения.

Ссылки 1. Обзор архитектуры RFS

Это компиляция и индекс ответов, данных на данный момент. Этот пост является вики сообщества, его может редактировать любой человек с репутацией 100+, и никто не получает от этого репутацию. Не стесняйтесь опубликовать свой собственный ответ и добавить ссылку на него сюда (или подождите, пока я это сделаю). В идеале, этот ответ должен быть просто кратким (с краткими записями, в то время как отдельные другие ответы будут содержать подробности).

Активно поддерживаемые в настоящее время системы:

• Cygwin. Уровень POSIX для Microsoft Windows. Используется для UNC-путей Windows.
• UWIN начиная с версии 1.3. Еще один уровень POSIX для Windows. Используется по крайней мере для путей //host/file сетевого файлообменника.
• ^{@OlivierDulac} IBM z/OS как упоминалось в баг-трекере POSIX, z/OS разрешает //pathname запросы к наборам данных MVS, а не к сетевым файлам. Example.

Несостоявшиеся системы

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

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

• ^@jillagre Tektronix Utek (подтверждено), где //host/path - это путь в распределенной файловой системе.

• ^@gilles QNX 4 с распределенной системой обработки FLEET, где //123/path - это /path на узле 123. (Упоминается в документации QNX 6.)
• ^@roaima AT&T SysV Release 3 (непроверено). //host/path в (прекращено в SVR4) RFS Remote File Sharing системе.
• ^@Scott SEL/Gould UTX-32 (непроверенный). Используется для //host/path.

Приложения, которые рассматривают //foo/bar специально для путей

• ^@Prem Perforce, где //depot/A/B/C/D ссылается на путь в depot.
• ^@WChargin Blender. В его конфигурации используется префикс // для относительных путей (к бленду, связанному с дата-блоком).

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

Хотя усилия до сих пор были небольшими, fork(), очевидно, является реальностью. Вот выдержка из страницы проекта подсистемы, перечисленной в разделе открытые вопросы:

пути

Какой лучший способ использовать пути Win32 в POSIX-приложениях? Идеи:

• перевести //<устройство>/<путь> в \\\. \<устройство>\<путь> (с особым случаем для букв дисков - //<буква>/<путь> => <буква>:\<путь> - и специальным escape //./ => \\\.\. Пути UNC могут быть указаны с помощью //unc/<путь>). Пути // зарезервированы стандартом для поведения, специфичного для конкретной реализации, а синтаксис //<буква>/ для экранирования путей Win32 широко используется в существующих средах совместимости POSIX

• эвристика для распознавания "голых" путей Win32 как таковых

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

Я не уверен, как это квалифицируется, поскольку я не уверен, насколько это было реализовано, но я подумал, что это полезное интересное описание проблемы.

Другое приложение: Blender обрабатывает ведущий // как ссылку на каталог проекта (каталог в который сохраняется в файле .blend ). Вот соответствующая страница руководства .

Это верно и для операционных систем, отличных от Unix (например, Windows).

POSIX утверждает в Обосновании для A.4.12 Pathname Resolution параграфы 9 и 10:

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

В других сетевых системах для той же цели используется конструкция //hostname; то есть, используется двойная начальная косая черта.

Это кажется подтверждает, что // означает "сетевой корень", или, по крайней мере, такова была идея, когда правило было включено в POSIX.

Следующие правила устраняют любое значение // в середине пути для / начального Pathname:

... поскольку нелидирующие последовательности из двух или более символов <слэш>
рассматриваются как один <слэш>, ...

Конечно, // начатое Имя Пути может расширить или изменить использование // внутри Имени Пути (не в начале). POSIX.1 позволяет это. Последнее подтверждает, что единственные разрешенные // находятся в начале имени пути.

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