W jakich systemach // foo / bar różni się od / foo / bar?

114

W całej specyfikacji POSIX istnieje przepis ( 1 , 2 , 3 ...), który pozwala implementacjom traktować ścieżkę zaczynającą się od dwóch /specjalnie.

Aplikacja POSIX (aplikacja napisana zgodnie ze specyfikacją POSIX, aby była przenośna dla wszystkich systemów zgodnych z POSIX) nie może założyć, że //foo/barjest taka sama jak /foo/bar(choć może założyć, że ///foo/barjest taka sama jak /foo/bar).

Jakie są te systemy POSIX (historyczne i nadal utrzymywane), które traktują //foospecjalnie? Wierzyłem (teraz okazało się, że się mylę ), że Microsoft wymusił udostępnienie POSIX dla ich wariantu Unix (XENIX) i prawdopodobnie warstwy Windows POSIX (czy ktoś może to potwierdzić?).

Jest używany przez Cygwin, który jest również warstwą podobną do POSIX dla Microsoft Windows. Czy są jakieś systemy inne niż Microsoft Windows? OpenVMS?

W systemach, w których //foo/barjest wyjątkowy, do czego służy? //host/pathdostęp do sieciowych systemów plików? Wirtualne systemy plików?

Czy niektóre aplikacje działające na systemach uniksowych - jeśli nie API systemu - traktują //foo/barścieżki specjalnie (w kontekstach, w których inaczej traktują /foo/barjako ścieżkę w systemie plików)?

Edytuj , od tego czasu zadałem pytanie na liście mailingowej grupy austin dotyczące pochodzenia //foo/barobsługi w specyfikacji, a dyskusja jest interesującą lekturą (przynajmniej z punktu widzenia archeologii).

filenames history portability slash Stéphane Chazelas
źródło
1
Powiązane: Oficjalny opis UNC (Universal Naming Convention)
Stéphane Chazelas,
1
@OlivierDulac, No. ls -ld ///również wyświetli ///, lspo prostu wyświetla plik, który ma wyświetlać tak, jak został podany. Szukam systemów lub aplikacji, które traktują // foo / var specjalnie (nie jako ścieżkę w systemie plików), jak robi to Cygwin.
Stéphane Chazelas,
1
standard ( pubs.opengroup.org/onlinepubs/009695399/basedefs/… ) mówi, jak wspomniałeś, „Ścieżka, która zaczyna się od dwóch kolejnych ukośników, może być interpretowana w sposób określony przez implementację” (więcej niż 2 rozwiązuje się do 1 /) . Przykład znaleziony w sieci: 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.... nie do końca jednak uniksowy ^^).
Olivier Dulac,
4
@DevSolar: naprawdę interesujący (i zaskakujący), ale powinniśmy trzymać się tylko POSIX, ponieważ poza POSIX wszystko jest możliwe ^^
Olivier Dulac
2
@edwardtorvalds, ponieważ pierwszym bitem jest adres URL: file://podobnie do http://i tak dalej. Na Chrome tutaj, w pracy, ścieżka UNC dla systemu Windows, którą teraz otworzyłem, jest file:////$MACHINE/$SHARENAME/index.html(chociaż z jakiegoś powodu również to rozumie file://$MACHINE/...)
przywołany

Odpowiedzi:

90

Jest to zestawienie i indeks dotychczasowych odpowiedzi. Ten post jest wiki społeczności , może go edytować każdy, kto ma ponad 100 reputacji i nikt nie zyskuje na nim reputacji. Możesz opublikować własną odpowiedź i dodać link do niej tutaj (lub poczekaj, aż to zrobię). Najlepiej byłoby, gdyby ta odpowiedź była streszczeniem (z krótkimi wpisami, podczas gdy poszczególne inne odpowiedzi zawierałyby szczegółowe informacje).

Obecnie aktywnie utrzymywane systemy:

Zepsute systemy

Aplikacje, które traktują //foo/barspecjalnie dla ścieżek

Stéphane Chazelas
źródło
3
Używanie //przestrzeni nazw zostało zaproponowane przez niektórych deweloperów jądra Linuksa dla obiektów metadanych Reiser4, ale nie sądzę, że ta propozycja kiedykolwiek zyskała na popularności w Namesys, ani też nigdy nie została zaimplementowana.
Jörg W Mittag
Sam Windows implementuje API POSIX ... jak to obsługuje wiodący podwójny ukośnik?
Kevin
1
Możemy dodać, że w Internecie zasoby zaczynające się od podwójnego ukośnika definiują inny katalog główny niż pojedynczy ukośnik.
Alex Gittemeier
@Kevin, tak, ja też w to wierzę (patrz pytanie), choć uważam, że był to opcjonalny składnik i tylko w niektórych wariantach systemu Windows, a teraz nie jest już dostępny. Jeśli masz więcej szczegółów, dodaj odpowiedź.
Stéphane Chazelas
@AlexGittemeier. Tak, zauważysz, że tak naprawdę zostało użyte w tej odpowiedzi ;-).
Stéphane Chazelas
16

Czy niektóre aplikacje działające na systemach uniksowych - jeśli nie API systemu - traktują // // foo / bar Paths specjalnie?

Wiem o Perforce, który używa //depot/A/B/C/DŚcieżek w celu odniesienia do składu. Perforce obsługuje także //Client/C/Dścieżki, na które wskazuje klient //depot/A/B/. W tym przypadku lokalny system plików może nie mieć tych ścieżek.

p4 filelog //depot/A/B/C/Dpokaże historię tego pliku, nawet jeśli nie ma pliku /depot/A/B/C/D.

p4 filelog C/D pokaże także historię tego pliku, jeśli zostanie wykonany z odpowiedniego katalogu.

Odniesienie: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

Prem
źródło
13

Kilka dekad temu Tektronix Utek (Unix oparty na BSD 4.2, najpierw na procesorach National Semiconductors 32016, a potem Motorola 68020 s) zapewniał coś o nazwie DFS (rozproszony system plików), pod którym //foo/barodnosił się do /barpliku na fooserwerze dfs. Później został przestarzały przez NFS firmy Sun.

Niestety nie wspomniałem jeszcze o tym, ale w końcu mogę znaleźć dokumentację Utek w mojej piwnicy i zaktualizować tę odpowiedź.

jlliagre
źródło
1
Potwierdzenie tej dyskusji na temat usenetu
Stéphane Chazelas
@ StéphaneChazelas Uważam, że ten link do dyskusji na temat Usenetu jest lepszy. Ten, który wybierzesz ma domenę / system operacyjny, ale nie Utek. Lub następna wiadomość (od twoich)
od autora (pracującego w Tektronix) implementacji RFS w domenie publicznej, która dotarła do BSD , opracowano zarówno DFS, jak i RFS.
Stéphane Chazelas
Implementacje Tektronix / BSD RFS najwyraźniej montowały zdalne systemy plików na zwykłych plikach, aby findna przykład uniknąć przechodzenia przez punkt montowania. Autor wyraźnie wyklucza //foo/bar(lub połączenie z Newcastle /../foo/bar)
Stéphane Chazelas,
inny wątek usenetowy, który potwierdza DFS
Stéphane Chazelas
7

Podążając za wskazówką z tej odpowiedzi . I czytanie strony 2-15 z podręcznika Bitsavers (dzięki @grawity ).

Współdzielone dane
Druga zasada projektowania rozproszonego systemu plików Domain / OS, domyślnie współdzielona, ​​oznacza globalną jednolitą przestrzeń nazw. Przestrzeń nazw rozproszonego systemu plików wydaje się użytkownikom podobnym do gigantycznego systemu plików dzielącego się czasem. Jest to tradycyjna hierarchiczna przestrzeń nazw UNIX, z tym wyjątkiem, że bezwzględne nazwy ścieżek mogą zaczynać się od nazwy katalogu głównego sieci (nazywanej //). Możliwe jest także wyrażenie nazw ścieżek względem katalogu głównego węzła lokalnego (katalog /).

Istnieje również starszy podręcznik z „Pierwszym drukiem: lipiec 1985”. Na stronie 1-4:

Podwójne ukośniki (//) na rysunku 1-2 reprezentują najwyższy poziom drzewa nazw, katalog główny sieci.

Mamy więc potwierdzenie, że domena / system operacyjny Apollo był używany //do rootowania sieci.

Społeczność
źródło
Myślę, że facet grawitacji jest głównym deweloperem Linuksa .
mikeserv
5

Inna aplikacja: Blender traktuje interlinię //jako odniesienie do katalogu projektu (katalogu, w którym .blendplik jest zapisany). Oto odpowiednia strona podręcznika .

Dotyczy to również systemów operacyjnych innych niż Unix (tj. Windows).

wchargin
źródło
5

ReactOS projekt - który jest darmowy i open-source realizacja jądrze NT i pokrewnych API - najwyraźniej zobowiązała się również realizować własne Interix -Jak POSIX podsystemu (choć oryginalny OS / 2 podsystem MS jest również wspomniane w kontekście , nie wspomina jest wykonany z analogu ReactOS) .

Choć dotychczasowe wysiłki były niewielkie , fork()najwyraźniej jest to rzeczywistość. Oto fragment strony projektu podsystemu wymienionej w części „ Otwarte problemy” :

ścieżki

Jaki jest najlepszy sposób korzystania ze ścieżek Win32 w aplikacjach POSIX? pomysły:

  • przetłumacz //<device>/<path> na \\.\<device>\<path> (ze specjalnym przypadkiem liter napędów - //<letter>/<path>=> <letter>:\<path>- i specjalnym klawiszem Escape //./<raw text>=> \\.\<raw text>. Ścieżki UNC można określić za pomocą //unc/<path>) . //ścieżki są zarezerwowane przez standard dla zachowania specyficznego dla implementacji, a //<letter>/składnia do ucieczki ścieżek Win32 jest szeroko stosowana w istniejących środowiskach kompatybilnych z POSIX

  • heurystyka w celu rozpoznania „nagich” ścieżek Win32 jako takich

  • rozróżnianie wielkości liter w ścieżkach i //ścieżkach Win32 (czy standard zezwala na tego rodzaju zachowanie specyficzne dla implementacji //ścieżek?) .

Nie jestem pewien, jak to się kwalifikuje, ponieważ nie jestem pewien, jak wiele z nich zostało zaimplementowanych, ale pomyślałem, że był to bardzo interesujący opis problemu.

mikeserv
źródło
XENIX nie miał podsystemu POSIX , Windows miał AFAIK. XENIX był Uniksem (początkowo oparty na Unixie V7, na który Microsoft kupił licencję od AT&T).
Stéphane Chazelas
1
Tutaj również można przeczytać o podsystemie interix / Windows POSIX
Stéphane Chazelas
@ StéphaneChazelas - całkiem. Prawie chcę zastąpić go linkiem, ale na końcu jest on trochę oparty na opiniach i tak naprawdę nie działa jako odniesienie ... ale nie usuwaj komentarza, proszę?
mikeserv
W każdym razie nie wspomina o //foo/barobsłudze. Nie znalazłem mocnych dowodów, że podsystem Windows POSIX lub Interix faktycznie je obsługiwały.
Stéphane Chazelas
@ StéphaneChazelas - Nie wiem, czy było to wyjątkowo niespójne, czy też pominięcie opcjonalnej części było jedynie niedopatrzeniem, ale lsaclpolecenie MKS jest zrozumiałe, \\machinename\driveletter:\pathpodczas gdy jego registrypolecenie było zrozumieniem tej formy lub opcjonalnie w// jakikolwiek sposób. Ponieważ zestaw MKS był poprzednikiem Interixa i był tym, co MS dostarczał dla wersji 1/2, pomyślałbym, że Interix musiał zaakceptować kompatybilną składnię dla tak podstawowej rzeczy.
mikeserv
4

W latach 80. SEL / Gould miał system operacyjny Unix o nazwie UTX-32, który był równoważny z Solaris; tzn. ścieżka dostępu zdalnego na hoście . Nie mogę znaleźć na nim żadnej dokumentacji, więc nie wiem, czy była to RFS, czy ewolucja równoległa (czy też AT&T//host/path/net/host/pathpathhostUkradłem nabył go od Goulda).

Scott
źródło
Dzięki. Czy przypadkiem miałbyś jakieś odniesienia ( //host/pathw UTX-32)?
Stéphane Chazelas
Możliwe, że mam dokument w formie papierowej w pudełku na strychu, ale jest mało prawdopodobne - (1) Nie przypominam sobie, aby kiedykolwiek miałem dużo dokumentacji (pamiętam pięciominutowy briefing ustny); (2) nawet gdybym go miał, mógłbym nie zabrać go do domu; (3) nawet jeśli zabrałem go do domu, prawdopodobnie wyrzuciłem go przez ostatnie 30 lat; i (4) nawet jeśli nadal go mam, prawdopodobnie nie będę w stanie go znaleźć. Och, także (0) spędziłem pięć minut na googlowaniu (bezskutecznie), zanim opublikowałem swoją odpowiedź.
Scott
4

Mam niejasną pamięć, że //host/pathnotacja została zastosowana w AT&T SysV.3 w ramach implementacji zdalnego udostępniania plików RFS . Zostało to ostatecznie porzucone w momencie wydania SysV.4 na rzecz prostszego, ale bardziej popularnego NFS od Sun Microsystems.

Nie mogę jednak znaleźć żadnych konkretnych odniesień do składni, a dokumentacja, którą właśnie przejrzałem, wydaje się wskazywać, że pomysł użytkownika wyraźnie określającego zdalną nazwę hosta byłby sprzeczny z zasadą niezależności lokalizacji.

Referencje 1. Przegląd architektury RFS

roaima
źródło
3
Przekaż to o RFS. Nie mogę znaleźć odniesień do //host/path. Wydaje się to sugerować, że sieciowe systemy plików muszą być montowane jawnie.
Stéphane Chazelas,
Dziekuje za przypomnienie. To jedna z części „dokumentacji, którą sprawdziłem”, więc dodam link do niej, jeśli nie masz nic przeciwko. Nadal zastanawiam się nad tym; może przyjść do mnie następnego dnia.
roaima,
4

Stany POSIX w uzasadnieniu dla A.4.12 paragrafy 9 i 10:

W niektórych systemach sieciowych konstrukcja /../nazwa_hosta/ jest używana do odniesienia do katalogu głównego innego hosta, a POSIX.1 pozwala na to zachowanie.

Inne systemy sieciowe używają konstrukcji // nazwa hosta w tym samym celu; oznacza to, że używany jest podwójny początkowy ukośnik.

To wydaje się potwierdzać, że //oznacza to „root sieci”, a przynajmniej taki był pomysł, kiedy reguła została zawarta w POSIX.

Poniższe reguły usuwają wszelkie znaczenie //środkowej części ścieżki dla /uruchomionej nazwy ścieżki :

... ponieważ nie wiodące sekwencje dwóch lub więcej <slash> znaków
są traktowane jako pojedynczy <slash>, ...

Oczywiście //uruchomiona nazwa ścieżki może rozszerzyć lub zmienić użycie //wewnątrz nazwy ścieżki (nie na początku). POSIX.1 pozwala na to. To ostatnie potwierdza, że ​​jedyne //dozwolone są na początku Ścieżki.


źródło