В спецификации 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обработки в спецификации, и обсуждение является интересным чтением (по крайней мере, с точки зрения археологии).
источник
ls -ld ///также будет отображаться///,lsпросто отображает файл, которому говорят, чтобы отобразить, как он был дан. Я ищу системы или приложения, которые обрабатывают // foo / var специально (не как путь в файловой системе), как Cygwin.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, хотя ^^).file://какhttp://и тому подобное. На chrome здесь на работе Windows UNC путь, который у меня сейчас открыт, естьfile:////$MACHINE/$SHARENAME/index.html(хотя по некоторым причинам он также понимаетfile://$MACHINE/...)Ответы:
Это компиляция и указатель ответов, данных до сих пор. Этот пост является вики-сообществом , его может редактировать любой, кто имеет более 100 репутации, и никто не получает репутацию из него. Не стесняйтесь оставить свой собственный ответ и добавить ссылку на него здесь (или подождите, пока я это сделаю). В идеале этот ответ должен быть просто кратким (с короткими записями, в то время как отдельные ответы должны содержать детали).
В настоящее время активно поддерживаются системы:
//host/fileпутейксетевым файлам.//pathnameзапросы к наборам данных MVS , а не к сетевым файлам. Пример .Несуществующие системы
@BinaryZebra Apollo Domain / OS (подтверждено). Также упоминается в Официальном описании UNC (Universal Naming Convention) в качестве возможного источника
//host/pathобозначений ( см. Также , стр. 2-15).По словам Донна Терри , именно HP (которая приобрела Apollo Computers) подтолкнула к включению этого положения в спецификацию POSIX для домена / ОС.
@jillagre Tektronix Utek ( подтверждено ), где указан
//host/pathпуть в распределенной файловой системе .//123/path/path//host/pathв (снят с производства в SVR4)Система удаленного обмена файлами RFS .//host/path.Приложения, которые обрабатывают
//foo/barспециально для путей//depot/A/B/C/Dотносится к пути в депо .//префикс для относительных путей (к смеси, связанной с блоком данных) .источник
//пространства имен было предложено некоторыми разработчиками ядра Linux для средств метаданных Reiser4, но я не думаю, что это предложение когда-либо получило распространение в Namesys и не было реализовано.Мне известно о 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
источник
Несколько десятилетий назад Tektronix Utek (Unix на базе BSD 4.2, сначала на процессорах National Semiconductors 32016, а затем на Motorola 68020 с) предоставлял нечто, называемое DFS (распределенная файловая система), в которой
//foo/barссылался на/barфайл наfooсервере dfs. Позже он был устаревшим из-за NFS от Sun.К сожалению, я еще не упомянул об этом, но мог бы в конечном итоге найти документацию по Utek в моем подвале и обновить этот ответ.
источник
findнапример, пересечения точки монтирования. Автор явно исключает//foo/bar(или связь Ньюкасла/../foo/bar) тамСледуя примеру этого ответа . И чтение страницы 2-15 из руководства от Bitsavers (спасибо @grawity ).
Существует также более старое руководство с «Первый выпуск: июль 1985 года». На стр. 1-4:
Итак, у нас есть подтверждение, что Домен / ОС от Apollo используется
//для сетевого рута.источник
Другое приложение: Blender рассматривает
//ведение как ссылку на каталог проекта (каталог, в котором сохранен.blendфайл). Вот соответствующая страница руководства .Это верно и для не Unix-подобных операционных систем (то есть для Windows).
источник
Проект ReactOS, представляющий собой бесплатную реализацию ядра NT и связанных API-интерфейсов с открытым исходным кодом, по-видимому, также предпринял попытку реализовать свою собственную Interix- подобную подсистему POSIX (хотя оригинальная подсистема MS OS / 2 также упоминается в контексте , не говоря уже о том, что сделан из аналога ReactOS) .
Хотя усилия до сих пор были небольшими ,
fork()это, очевидно, реальность. Вот выдержка из страницы проекта подсистемы, как указано в списке открытых вопросов :Я не уверен, как это квалифицируется, поскольку я не уверен, сколько из этого было реализовано, но я подумал, что это было полезно интересное описание проблемы.
источник
//foo/barобработки. Я не нашел убедительных доказательств того, что подсистема Windows POSIX или Interix фактически обрабатывали их до сих пор.lsaclдолжна была понять спецификацию, в\\machinename\driveletter:\pathто время как ееregistryкоманда была специально предназначена для понимания этой формы или, в случае необходимости, в//любом случае. Поскольку набор MKS был предшественником Interix и был тем, что MS поставляла для версий 1/2, я бы подумал, что Interix должен был принять совместимый синтаксис для такой базовой вещи.В 1980-х годах SEL / Gould имела операционную систему Unix под названием UTX-32, в которой была аналога Solaris; т.е. удаленный доступ к пути на хосте . Я не могу найти какую-либо документацию по нему, поэтому я не знаю, был ли это RFS или параллельная эволюция (или AT & T
//host/path/net/host/pathpathhostукралприобрел его у Гульда).источник
//host/pathв UTX-32)?У меня есть расплывчатая память о том, что
//host/pathнотация использовалась в AT & T SysV.3 как часть его реализации RFS Remote File Sharing . В конечном итоге это было прекращено в то время, когда была выпущена SysV.4 в пользу более простой, но более популярной NFS от Sun Microsystems.Однако я не могу найти каких-либо конкретных ссылок на синтаксис, и документация, которую я только что рассмотрел, указывает на то, что идея пользователя, явно указывающего удаленное имя хоста, противоречила бы принципу независимости от местоположения.
Список литературы 1. RFS Архитектурный обзор
источник
//host/path. Кажется, подразумевается, что сетевые файловые системы должны быть смонтированы явно.POSIX заявляет в Обосновании для A.4.12 Разрешения имени пути Пункты 9 и 10:
Это , кажется , чтобы подтвердить , что
//означает «сетевой корень», или , по крайней мере, это была идея , когда правило было включено в POSIX.Правила следуют, чтобы удалить любое значение
//в середине пути для/начального пути:Конечно,
//начальный Pathname может расширяться или изменять использование//внутри Pathname (не в начале). POSIX.1 позволяет это. Последнее подтверждает, что//разрешено только в начале пути.источник