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

114

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

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

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

Он используется Cygwin, который также является POSIX-подобным слоем для Microsoft Windows. Существуют ли системы, отличные от Microsoft Windows? OpenVMS?

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

Некоторые приложения, работающие на Unix-лайках, если не системный API, обрабатывают //foo/barпути специально (в тех случаях, когда они иначе трактуются /foo/barкак путь в файловой системе)?

Edit , с тех пор я задал вопрос в списке рассылки Austin-Group о происхождении //foo/barобработки в спецификации, и обсуждение является интересным чтением (по крайней мере, с точки зрения археологии).

filenames  history  portability  slash 
— Стефан Шазелас
источник
1
— Стефан Шазелас
1
@OlivierDulac, No. ls -ld ///также будет отображаться ///, lsпросто отображает файл, которому говорят, чтобы отобразить, как он был дан. Я ищу системы или приложения, которые обрабатывают // foo / var специально (не как путь в файловой системе), как Cygwin.
— Стефан Шазелас
1
Стандарт ( pubs.opengroup.org/onlinepubs/009695399/basedefs/… ), как вы упомянули, гласит: «Имя пути, начинающееся с двух последовательных слешей, может быть интерпретировано способом, определяемым реализацией» (более 2 преобразуется в 1 /). , Пример, найденный в сети: austingroupbugs.net/view.php?id=83 ( IBM's z/OS resolves //pathname requests to MVS datasets (as opposed to the hierarchical filesystem (HFS)) (......) Additionally, z/OS would not accept or recognize additional "directory" or "file" components appended to such paths.... не совсем unix, хотя ^^).
— Оливье Дюлак
4
@DevSolar: действительно интересно (и удивительно), но мы должны придерживаться только POSIX, так как из POSIX все возможно. ^^
— Оливье Дюлак
2
@edwardtorvalds, потому что первый бит - это URL:, file://как http://и тому подобное. На chrome здесь на работе Windows UNC путь, который у меня сейчас открыт, есть file:////$MACHINE/$SHARENAME/index.html(хотя по некоторым причинам он также понимает file://$MACHINE/...)
— admalledd

Ответы:

90

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

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

Несуществующие системы

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

— Stéphane Chazelas
источник
3
Использование //пространства имен было предложено некоторыми разработчиками ядра Linux для средств метаданных Reiser4, но я не думаю, что это предложение когда-либо получило распространение в Namesys и не было реализовано.
— Jörg W Mittag
Сама Windows реализует POSIX API ... как это обрабатывает двойную косую черту?
— Кевин
1
Мы можем добавить, что в Интернете ресурсы, начинающиеся с двойной косой черты, определяют корень, отличный от одиночной косой черты.
— Алекс Гиттемайер
@Kevin, да, я тоже в это верю (см. Вопрос), хотя я думаю, что это был необязательный компонент, и только в некоторых вариантах Windows, и в настоящее время прекращено. Если у вас есть более подробная информация, пожалуйста, добавьте ответ.
— Стефан Шазелас
@AlexGittemeier. Да, вы заметите, что это на самом деле используется в этом ответе ;-).
— Стефан Шазелас
16

Некоторые приложения, работающие на Unix-лайках - если не системный API - обрабатывают // пути foo / bar специально?

Мне известно о Perforce, которая использует //depot/A/B/C/DПути для ссылки на Депо. Perforce также поддерживает //Client/C/DPaths, когда Клиент указывает на //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

— Prem
источник
13

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

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

— jlliagre
источник
1
Подтверждено этим обсуждением Usenet
— Стефан Шазелас
@ StéphaneChazelas Я считаю, что эта ссылка на обсуждение Usenet лучше. Тот, который вы выбираете, имеет домен / ОС, но не Utek. Или следующее сообщение (от вашего)
— Стефан Шазелас
Реализации Tektronix / BSD RFS, по-видимому, монтировали удаленные файловые системы в обычные файлы, чтобы избежать, findнапример, пересечения точки монтирования. Автор явно исключает //foo/bar(или связь Ньюкасла /../foo/bar) там
— Стефан Chazelas
— Стефан Шазелас
7

Следуя примеру этого ответа . И чтение страницы 2-15 из руководства от Bitsavers (спасибо @grawity ).

Совместно используемые данные
Второй принцип проектирования распределенной файловой системы Domain / OS, разделяемый по умолчанию, подразумевает глобальное единое пространство имен. Пространство имен распределенной файловой системы представляется пользователям как пространство гигантской файловой системы с временным разделением. Это традиционное иерархическое пространство имен UNIX, за исключением того, что абсолютные пути могут начинаться с имени сетевого корня (называемого //). Также возможно указывать имена путей относительно корня локального узла (каталог /).

Существует также более старое руководство с «Первый выпуск: июль 1985 года». На стр. 1-4:

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

Итак, у нас есть подтверждение, что Домен / ОС от Apollo используется //для сетевого рута.

— Сообщество
источник
Я думаю, что этот парень - главный разработчик Linux .
— mikeserv
5

Проект ReactOS, представляющий собой бесплатную реализацию ядра NT и связанных API-интерфейсов с открытым исходным кодом, по-видимому, также предпринял попытку реализовать свою собственную Interix- подобную подсистему POSIX (хотя оригинальная подсистема MS OS / 2 также упоминается в контексте , не говоря уже о том, что сделан из аналога 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 (допускает ли стандарт такого рода специфичное для реализации поведение для //путей?) .

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

— mikeserv
источник
У XENIX не было подсистемы POSIX , в Windows был AFAIK. XENIX был Unix (изначально основанный на Unix V7, лицензия на которую Microsoft купила у AT & T).
— Стефан Шазелас
1
Приятно читать и здесь о подсистеме Interix / POSIX для Windows
— Стефан Шазелас
@ StéphaneChazelas - довольно. Я почти хочу заменить свою ссылку на нее, но в конце она немного основана на мнениях и на самом деле не работает как ссылка ... но не удаляйте комментарий, пожалуйста?
— mikeserv
В любом случае, это не касается //foo/barобработки. Я не нашел убедительных доказательств того, что подсистема Windows POSIX или Interix фактически обрабатывали их до сих пор.
— Стефан Шазелас
@ StéphaneChazelas - Я не знаю, было ли это просто крайне незаметно, или если опускать необязательную часть было просто недосмотром, но команда MKS lsaclдолжна была понять спецификацию, в \\machinename\driveletter:\pathто время как ее registryкоманда была специально предназначена для понимания этой формы или, в случае необходимости, в// любом случае. Поскольку набор MKS был предшественником Interix и был тем, что MS поставляла для версий 1/2, я бы подумал, что Interix должен был принять совместимый синтаксис для такой базовой вещи.
— mikeserv
4

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

— Скотт
источник
Благодарю. Вы случайно не упоминали об этом ( //host/pathв UTX-32)?
— Стефан Шазелас
Вполне возможно , что у меня есть документ в бумажном виде в коробке на чердаке, но вряд ли - (1) Я не помню , когда - либо иметь много документации (я помню пяти минут устного сообщения ); (2) даже если бы у меня было это, я, возможно, не взял бы это домой; (3) даже если бы я взял его домой, я, вероятно, выбросил его за последние 30 лет; и (4) даже если у меня все еще есть это, я вероятно не буду в состоянии найти это. О, также (0) Я потратил пять минут на поиски в Google (безрезультатно), прежде чем опубликовать свой ответ.
— Скотт
4

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

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

Список литературы 1. RFS Архитектурный обзор

— roaima
источник
3
Основать это о RFS. Я не могу найти ссылки на //host/path. Кажется, подразумевается, что сетевые файловые системы должны быть смонтированы явно.
— Стефан Шазелас
Спасибо за напоминание. Это одна из частей "документации, которую я рассмотрел", поэтому я добавлю ссылку на нее, если вы не возражаете. Я все еще ломаю голову над этим; это может прийти ко мне на следующий день или около того.
— Ройма
4

POSIX заявляет в Обосновании для A.4.12 Разрешения имени пути Пункты 9 и 10:

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

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

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

Правила следуют, чтобы удалить любое значение //в середине пути для /начального пути:

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.