// foo / bar는 어떤 시스템에서 / foo / bar와 다른가?

114

POSIX 사양에는 구현이 두 가지로 시작하는 경로를 특별히 처리 할 수 ​​있도록 ( 1 , 2 , 3 ...) 조항이 /있습니다.

POSIX의 응용 프로그램 즉지지 않습니다합니다 (POSIX 사양에 작성된 응용 프로그램은 모든 POSIX 호환 시스템에 이식하는) //foo/bar과 동일하다 /foo/bar(그들은 그 가정 할 수 있지만 ///foo/bar동일하다 /foo/bar).

이제 //foo특별하게 취급하는 POSIX 시스템 (역사적이며 여전히 유지 관리되는)은 무엇입니까? POSIX 조항은 Microsoft가 유닉스 변형 (XENIX) 및 Windows POSIX 계층 (누구도 확인할 수 있습니까?)에 대해 추진하고 있다고 믿었습니다 (지금은 잘못 입증되었습니다 ).

Cygwin에서 사용되며 Microsoft Windows의 POSIX와 유사한 계층이기도합니다. Microsoft 이외의 Windows 시스템이 있습니까? OpenVMS?

//foo/bar특별한 시스템에서는 어떤 용도로 사용됩니까? //host/path네트워크 파일 시스템 액세스를 위해? 가상 파일 시스템?

시스템 API가 아닌 경우 유닉스 계열에서 실행되는 일부 응용 프로그램 은 //foo/bar경로를 특수하게 처리 /foo/bar합니까 (파일 시스템의 경로로 처리 되는 컨텍스트에서 )?

Edit , 나는 austin-group 메일 링리스트//foo/bar 에서 스펙 의 처리 원점에 대한 질문을했으며 , 토론은 흥미로운 글입니다 (적어도 고고학의 관점에서).

filenames  history  portability  slash 
— 스테판 샤 첼라
소스
1
— 스테판 Chazelas가
1
@OlivierDulac는 번호 ls -ld ///도 표시 할 것 ///, ls바로이 주어진로 표시하라고중인 파일을 표시합니다. Cygwin과 같이 // foo / var를 파일 시스템의 경로가 아닌 특수하게 처리하는 시스템이나 응용 프로그램을 찾고 있습니다.
— Stéphane Chazelas
1
standard ( 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.... 정확하게 유닉스는 아니지만 ^^).
— Olivier Dulac
4
@DevSolar : 정말 interresting (그리고 놀라운)이지만 POSIX에서 아무것도 가능 하므로 POSIX에만 충실해야 합니다 ^^
— Olivier Dulac
2
@edwardtorvalds는 첫 번째 비트가 URL : file://이므로 비슷합니다 http://. 나는 열려있는 여기 일 윈도우 UNC 경로에서 크롬에 지금 file:////$MACHINE/$SHARENAME/index.html(어떤 이유로도 이해하지만 file://$MACHINE/...)
— admalledd

답변:

90

이것은 지금까지 주어진 답변의 편집 및 색인입니다. 이 게시물은 커뮤니티 위키 이며 100 명 이상의 평판을 가진 사람이 편집 할 수 있으며 아무도 평판을 얻지 못합니다. 자신의 답변을 게시하고 여기에 링크를 추가하십시오 (또는 내가 기다릴 때까지 기다리십시오). 이상적으로이 답변은 요약 일뿐입니다 (짧은 항목이있는 반면 다른 개별 답변에는 세부 사항이 있음).

현재 적극적으로 유지 관리되는 시스템 :

기능이없는 시스템

//foo/bar경로를 특별히 다루는 응용 프로그램

— Stéphane Chazelas
소스
3
//네임 스페이스 사용은 Reiser4의 메타 데이터 기능을 위해 일부 Linux 커널 개발자에 의해 제안되었지만이 제안이 Namesys 내에서 인기를 얻지 못하거나 구현되지 않았다고 생각합니다.
— Jörg W Mittag 2012 년
Windows 자체는 POSIX API를 구현합니다. 어떻게 이중 슬래시를 처리합니까?
— Kevin
1
웹에서 더블 슬래시로 시작하는 리소스는 단일 슬래시와 다른 루트를 정의합니다.
— Alex Gittemeier
@Kevin, 그렇습니다. 선택적 인 구성 요소라고 생각하고 Windows의 일부 변형에서만 가능하지만 현재 중단되었습니다. 자세한 내용이 있으면 답변을 추가하십시오.
— Stéphane Chazelas
@AlexGittemeier. 예, 실제로이 답변에 사용됩니다 . ;-).
— Stéphane Chazelas
16

시스템 API가 아닌 경우 유닉스 계열에서 실행되는 일부 응용 프로그램이 // foo / bar 경로를 특수하게 처리합니까?

//depot/A/B/C/D경로를 사용 하여 저장소를 참조하는 Perforce를 알고 있습니다. Perforce는 //Client/C/D클라이언트가를 가리킬 때 경로 도 지원 합니다 //depot/A/B/. 여기서 로컬 FileSystem에는 이러한 경로가 없을 수 있습니다.

p4 filelog //depot/A/B/C/Dfile이 없어도 해당 파일의 기록을 표시합니다 /depot/A/B/C/D.

p4 filelog C/D 적절한 디렉토리에서 실행 된 경우 해당 파일의 기록도 표시합니다.

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

— 프렘
소스
13

수십 년 전에 Tektronix Utek (BSD 4.2 기반 Unix, 내셔널 세미 컨덕터 32016 CPU, 모토로라 68020 )은 dfs 서버 //foo/bar의 /bar파일을 참조 하는 DFS (분산 파일 시스템)를 제공했습니다 foo. 나중에 Sun의 NFS에서 폐기되었습니다.

불행히도, 나는 그것을 뒷받침하지는 않았지만 결국에는 지하실에서 Utek 문서를 찾아서이 회신을 업데이트 할 수 있습니다.

— 젤리아 그레
소스
1
— Stéphane Chazelas
@ StéphaneChazelas이 Usenet 토론 링크 가 더 좋다고 생각합니다. 선택한 것은 Domain / OS이지만 Utek은 없습니다. 또는 다음 메시지 (귀하의 메시지 )
— Stéphane Chazelas
텍트로닉스 / BSD RFS 구현find 은 예를 들어 마운트 포인트를 가로 지르지 않기 위해 원격 파일 시스템을 일반 파일 에 마운트 한 것 같습니다. 저자는 그곳 //foo/bar에서 명시 적으로 (또는 뉴캐슬 연결의 /../foo/bar) 규칙을 배제합니다
— Stéphane Chazelas
— Stéphane Chazelas
7

이 답변 의 리드에 따라 . 그리고에서 2-15 페이지를 읽고 Bitsavers에서 수동 (감사 @grawity ).

공유 데이터
기본적으로 공유되는 Domain / OS 분산 파일 시스템의 두 번째 설계 원칙은 전역 적으로 통일 된 네임 스페이스를 의미합니다. 분산 파일 시스템의 이름 공간은 거대한 시분할 파일 시스템의 이름 공간과 같이 사용자에게 나타납니다. 절대 경로 이름이 네트워크 루트 이름 (///)으로 시작될 수 있다는 점을 제외하면 일반적인 UNIX 계층 이름 공간입니다. 로컬 노드의 루트 (/ 디렉토리)에 상대적인 경로 이름을 표현할 수도 있습니다.

"첫 인쇄 : 1985 년 7 월" 의 오래된 매뉴얼 도 있습니다 . 1-4 페이지의

그림 1-2의 이중 슬래시 (//)는 네이밍 트리의 최상위 레벨 인 네트워크 루트 디렉토리를 나타냅니다.

따라서 Apollo의 Domain / OS가 //네트워크 루트에 사용되었음을 확인했습니다 .

— 커뮤니티
소스
나는 grawity가 주요 아치 리눅스 개발자 라고 생각한다 .
— mikeserv
5

ReactOS에의 프로젝트 - 신약 커널 및 관련 API의 무료 및 오픈 소스 구현 - 분명히 또한 자체 구현하기 위해 수행하고있다 는 Interix -like POSIX 하위 시스템을 MS의 원래 OS / 2 서브 시스템도되지만 ( 상황에 언급 , 언급하지 ReactOS 아날로그로 만들어 짐) .

노력은 지금까지왔다 비록 작은 , fork()분명히 현실이다. 다음은 공개 이슈 아래에 나열된 서브 시스템 프로젝트 페이지에서 발췌 한 내용입니다 .

경로

POSIX 응용 프로그램에서 Win32 경로를 사용하는 가장 좋은 방법은 무엇입니까? 아이디어 :

  • translate //<device>/<path> into \\.\<device>\<path> (드라이브 문자- //<letter>/<path>=> <letter>:\<path>-및 특수 이스케이프 //./<raw text>=> \\.\<raw text>. UNC 경로는로 지정할 수 있음 //unc/<path>) . //경로는 구현 별 동작에 대한 표준으로 예약되어 있으며 //<letter>/Win32 경로를 이스케이프 하는 구문은 기존 POSIX 호환성 환경에서 널리 사용됩니다.

  • "맨손"Win32 경로를 인식하는 휴리스틱

  • Win32 경로 및 //경로에 대한 대소 문자를 구분하지 않는 조회 (표준은// 경로에 대해 이러한 종류의 구현 특정 동작을 허용 합니까?) .

나는 그것이 얼마나 많이 구현되었는지 확실하지 않기 때문에 그것이 어떻게 자격이되는지 확실하지 않지만 문제에 대해 유용한 흥미로운 설명이라고 생각했습니다.

— mikeserv
소스
XENIX에는 POSIX 하위 시스템 이 없었고 Windows에는 AFAIK가있었습니다. XENIX는 Unix (초기 Microsoft가 AT & T로부터 라이센스를 구입 한 Unix V7을 기반으로 함)였습니다.
— Stéphane Chazelas
1
니스 읽어 여기 INTERIX / 윈도우 POSIX 하위 시스템에 대한뿐만 아니라
— 스테판 Chazelas가
@ StéphaneChazelas-아주. 링크를 거의 바꾸고 싶지만 결국에는 약간의 의견을 기반으로하며 실제로 참조로 작동하지는 않지만 주석을 삭제하지 마십시오.
— mikeserv 2012 년
어쨌든 //foo/bar처리 는 언급되지 않습니다 . Windows POSIX 하위 시스템 또는 Interix가 실제로 지금까지이를 처리했다는 강력한 증거를 찾지 못했습니다.
— Stéphane Chazelas
@ StéphaneChazelas-매우 불분명하거나 선택 부분을 생략 하는 것이 감독 일 경우 MUN lsacl명령은 이해가 가능 \\machinename\driveletter:\path하지만 registry명령은 해당 형식을 이해하거나 선택적으로// 어느 쪽이든 이해할 수 있습니다. MKS 키트는 Interix의 전신이었고 MS가 버전 1/2에 제공 한 것이므로 Interix가 이러한 기본 사항에 대해 호환되는 구문을 허용해야한다고 생각합니다.
— mikeserv
4

1980 년대에 SEL / Gould 는 UTX-32라는 Unix 운영 체제를 가지고 있었으며 이는 Solaris 와 동일합니다 . 즉, 호스트의 원격 액세스 경로 입니다 . 나는 그것에 대한 문서를 찾을 수 없으므로 이것이 RFS인지 아니면 병렬 진화인지 (또는 AT & T인지) 모른다.//host/path/net/host/pathpathhost스톨 굴드에서 인수).

— 스캇
소스
감사. //host/path우연히 그 ( UTX-32) 에 대한 언급이 있습니까?
— Stéphane Chazelas
내가 내 다락방에서 상자에 하드 카피 문서가 가능성이 있지만, 확률이 낮다 - (1) 내가 기억하지 않습니다 지금까지 많은 문서를 가지고 (나는 5 분 구두 브리핑을 기억); (2) 가지고 있어도 집에 가져 가지 않았을 수도 있습니다. (3) 집에 가져가도 지난 30 년 동안 어느 정도 시간을 버렸을 것이다. (4) 그래도 가지고 있어도 찾을 수 없을 것입니다. 또한, (0) 5 분 동안 답변을 게시하기 전에 인터넷 검색을했습니다.
— Scott
4

RFS 원격 파일 공유 구현의 //host/path일부로 AT & T SysV.3에서이 표기법이 사용 되었다는 모호한 기억이 있습니다. 이것은 SysV.4가 Sun Microsystems 의 단순하지만 널리 사용되는 NFS 를 위해 출시 될 때쯤에 포기되었습니다 .

그러나 구문에 대한 구체적인 참조를 찾을 수 없으며 방금 검토 한 문서는 사용자가 원격 호스트 이름을 명시 적으로 지정한다는 아이디어가 위치 독립성의 설계 원칙에 반대되는 것으로 나타났습니다.

참조 1. RFS 아키텍처 개요

— 로 이마
소스
3
RFS에 대해이 사실을 알려주십시오. 에 대한 참조를 찾을 수 없습니다 //host/path. 네트워크 파일 시스템이 명시 적으로 마운트되어야 함을 의미합니다.
— Stéphane Chazelas
상기시켜 주셔서 감사합니다. 이것은 "내가 검토 한 문서"중 하나이므로 마음에 들지 않으면 링크를 추가하겠습니다. 나는 아직도 이것에 대해 수수께끼를 짓고있다. 다음 날쯤에 나에게 올 수도 있습니다.
— roaima
4

A.4.12 경로명 분석 단락 9 및 10 에 대한 이론적 근거의 POSIX 상태 :

일부 네트워크 시스템에서 /../hostname/ 구성은 다른 호스트의 루트 디렉토리를 참조하는 데 사용되며 POSIX.1은이 동작을 허용합니다.

다른 네트워크 시스템은 같은 목적으로 // hostname 구문을 사용합니다. 즉, 이중 초기 슬래시가 사용됩니다.

이것은 "네트워크 루트" 를 의미하거나 최소한 규칙이 POSIX에 포함되었을 때의 아이디어라는 것을 확인하는 것 같습니다// .

시작된 경로 이름 //에 대한 경로 중간의 의미를 제거하기 위해 규칙이 따릅니다 /.

... 두 개 이상의 <slash> 문자
로 구성된 비 순차적 시퀀스 는 단일 <slash>로 취급되므로 ...

물론, //시작된 경로 이름은 시작이 //아닌 경로 이름 내부 의 사용을 확장하거나 변경할 수 있습니다 . POSIX.1은 이것을 허용합니다. 이것은 마지막으로 //허용 되는 유일한 경로 이름의 시작 임을 확인합니다 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.