// foo / bar nào khác với / foo / bar?

114

Trong suốt đặc tả POSIX, có quy định ( 1 , 2 , 3 ...) để cho phép các triển khai xử lý một đường dẫn bắt đầu bằng hai cách /đặc biệt.

Ứng dụng POSIX (một ứng dụng được viết theo đặc tả POSIX có thể di động tới tất cả các hệ thống tuân thủ POSIX) không thể cho rằng //foo/barnó giống như /foo/bar(mặc dù chúng có thể giả định ///foo/barlà giống như /foo/bar).

Bây giờ những hệ thống POSIX nào (lịch sử và vẫn được duy trì) đối xử //foođặc biệt là gì? Tôi tin rằng (hiện tại tôi đã được chứng minh là sai ) rằng việc cung cấp POSIX đã được Microsoft thúc đẩy cho biến thể Unix (XENIX) và có thể là lớp POSIX của Windows (có ai có thể xác nhận điều đó không?).

Nó được Cygwin sử dụng, cũng là một lớp giống như POSIX cho Microsoft Windows. Có bất kỳ hệ thống Windows không phải Microsoft? OpenVMS?

Trên các hệ thống //foo/barđặc biệt, nó được sử dụng để làm gì? //host/pathđể truy cập hệ thống tập tin mạng? Hệ thống tập tin ảo?

Có phải một số ứng dụng chạy trên Unixif thích Unix không phải là các //foo/barđường dẫn xử lý API API của hệ thống một cách đặc biệt (trong bối cảnh mà chúng thường coi /foo/barlà đường dẫn trên hệ thống tệp)?

Chỉnh sửa , tôi đã từng hỏi một câu hỏi trong danh sách gửi thư của nhóm austin về nguồn gốc //foo/barxử lý trong thông số kỹ thuật và cuộc thảo luận là một bài đọc thú vị (ít nhất là từ quan điểm khảo cổ học).

filenames  history  portability  slash 
— Stéphane Chazelas
nguồn
1
— Stéphane Chazelas
1
@OlivierDulac, số ls -ld ///cũng sẽ hiển thị ///, lschỉ hiển thị tệp mà nó được yêu cầu hiển thị như được đưa ra. Tôi đang tìm kiếm các hệ thống hoặc ứng dụng xử lý // foo / var đặc biệt (không phải là đường dẫn trên hệ thống tệp) như Cygwin.
— Stéphane Chazelas
1
tiêu chuẩn ( pubs.opengroup.org/onlinepub/009695399/basingefs/ mẹo ) nói, như bạn đã đề cập, "Một tên đường dẫn bắt đầu bằng hai dấu gạch chéo liên tiếp có thể được hiểu theo cách xác định thực hiện" (hơn 2 độ phân giải thành 1 /) . Một ví dụ được tìm thấy trên mạng: 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.... không chính xác là unix, mặc dù vậy ^^).
— Olivier Dulac
4
@DevSolar: thực sự can thiệp (và đáng ngạc nhiên), nhưng chúng ta chỉ nên sử dụng POSIX, vì ngoài POSIX, mọi thứ đều có thể ^^
— Olivier Dulac
2
@edwardtorvalds vì bit đầu tiên là URL : file://, giống nhau http://và như vậy. Trên chrome ở đây tại nơi làm việc, một đường dẫn UNC mà tôi đã mở bây giờ là file:////$MACHINE/$SHARENAME/index.html(mặc dù vì một số lý do nó cũng hiểu file://$MACHINE/...)
— admalledd

Câu trả lời:

90

Đây là một tổng hợp và chỉ mục của các câu trả lời cho đến nay. Bài đăng này là wiki cộng đồng , nó có thể được chỉnh sửa bởi bất kỳ ai có hơn 100 danh tiếng và không ai có được danh tiếng từ nó. Vui lòng gửi câu trả lời của riêng bạn và thêm một liên kết đến nó ở đây (hoặc chờ tôi làm điều đó). Lý tưởng nhất, câu trả lời này chỉ nên là một bản tóm tắt (với các mục ngắn trong khi các câu trả lời khác sẽ có chi tiết).

Hệ thống hiện đang tích cực bảo trì:

Hệ thống không còn tồn tại

Các ứng dụng //foo/barđặc biệt dành cho đường dẫn

— Stéphane Chazelas
nguồn
3
Việc sử dụng //không gian tên được đề xuất bởi một số nhà phát triển nhân Linux cho các cơ sở siêu dữ liệu của Reiser4, nhưng tôi không nghĩ rằng đề xuất này đã từng đạt được lực kéo trong Nameys, cũng chưa từng được thực hiện.
— Jörg W Mittag
Bản thân Windows thực hiện API POSIX ... làm thế nào để xử lý một dấu gạch chéo kép hàng đầu?
— Kevin
1
Chúng ta có thể thêm rằng trên web, các tài nguyên bắt đầu bằng dấu gạch chéo kép xác định một gốc khác với dấu gạch chéo đơn.
— Alex Gittemeier
@Kevin, vâng tôi cũng tin điều đó (xem câu hỏi), mặc dù tôi nghĩ rằng nó là một thành phần tùy chọn và chỉ trên một số biến thể của Windows và hiện đã ngừng. Nếu bạn có thêm chi tiết, xin vui lòng thêm một câu trả lời.
— Stéphane Chazelas
@AlexGittemeier. Có, bạn sẽ nhận thấy nó thực sự được sử dụng trong câu trả lời này ;-).
— Stéphane Chazelas
16

Có phải một số ứng dụng chạy trên Unixif thích Unix không phải là các API Đường dẫn // foo / bar của hệ thống đặc biệt không?

Tôi biết về Perforce sử dụng //depot/A/B/C/DĐường dẫn để chỉ Kho. Perforce cũng hỗ trợ //Client/C/DĐường dẫn, khi Máy khách đang trỏ tới //depot/A/B/. Ở đây, FileSystem cục bộ có thể không có các Path này.

p4 filelog //depot/A/B/C/Dsẽ hiển thị lịch sử của tập tin đó, mặc dù không có tập tin nào /depot/A/B/C/D.

p4 filelog C/D cũng sẽ hiển thị lịch sử của tập tin đó, nếu được thực hiện từ Thư mục thích hợp.

Tham khảo: https://www.perforce.com/perforce/r12.1/manuals/cmdref/o.fspecs.html

— Prem
nguồn
13

Cách đây vài thập kỷ, Tektronix Utek (Unix dựa trên BSD 4.2, lần đầu tiên trên CPU Bán dẫn Quốc gia 32016 sau đó là Motorola 68020 ) đã cung cấp một thứ gọi là DFS (hệ thống tệp phân tán) trong đó //foo/barđề cập đến /bartệp trên foomáy chủ dfs. Nó sau đó đã bị lỗi thời bởi NFS của Sun.

Thật không may, tôi chưa tham khảo để ủng hộ điều đó nhưng cuối cùng tôi có thể tìm thấy một số tài liệu Utek trong hầm của mình và cập nhật câu trả lời này.

— jlliagre
nguồn
1
Được chứng thực bởi cuộc thảo luận usenet này
— Stéphane Chazelas
@ StéphaneChazelas Tôi tin rằng liên kết này đến thảo luận Usenet là tốt hơn. Cái bạn chọn có Domain / OS nhưng không phải Utek. Hoặc tin nhắn tiếp theo (từ của bạn)
— Stéphane Chazelas
Việc triển khai RFS của Tektronix / BSD rõ ràng đã gắn các hệ thống tệp từ xa trên các tệp thông thường để tránh findtrường hợp đi qua điểm gắn kết. Tác giả rõ ràng loại trừ //foo/bar(hoặc kết nối của Newcastle /../foo/bar) ở đó
— Stéphane Chazelas
— Stéphane Chazelas
7

Theo sự dẫn dắt từ câu trả lời này . Và đọc trang 2-15 từ hướng dẫn từ Bitsavers (nhờ @grawity ).

Dữ liệu được chia sẻ
Nguyên tắc thiết kế thứ hai của hệ thống tệp phân tán Miền / Hệ điều hành, chia sẻ theo mặc định, ngụ ý một không gian tên thống nhất toàn cầu. Không gian tên của hệ thống tệp phân tán xuất hiện cho người dùng giống như hệ thống tệp chia sẻ thời gian khổng lồ. Đó là một không gian tên phân cấp UNIX truyền thống, ngoại trừ tên đường dẫn tuyệt đối có thể bắt đầu bằng tên của gốc mạng (được gọi là //). Cũng có thể biểu thị tên đường dẫn liên quan đến thư mục gốc của nút cục bộ (thư mục /).

Ngoài ra còn có một hướng dẫn cũ hơn với "In lần đầu: Tháng Bảy, 1985". Trên trang 1-4:

Dấu gạch chéo kép (//) trong Hình 1-2 biểu thị mức cao nhất của cây đặt tên, thư mục gốc của mạng.

Vì vậy, chúng tôi đã xác nhận rằng Tên miền / HĐH từ Apollo được sử dụng //cho root mạng.

— cộng đồng
nguồn
Tôi nghĩ rằng anh chàng grawity là chuyên ngành kiến trúc Linux dev .
— mikeerv
5

Các ReactOS dự án - đó là một ứng dụng miễn phí và mã nguồn mở của kernel NT và API liên quan - dường như đã thực hiện cũng để thực hiện riêng của mình Interix hệ thống phụ -like POSIX (mặc dù ban đầu OS / 2 hệ thống phụ MS cũng được đề cập trong bối cảnh , không đề cập đến được làm bằng một chất tương tự ReactOS) .

Mặc dù những nỗ lực cho đến nay là nhỏ , fork()rõ ràng là một thực tế. Đây là một đoạn trích từ trang dự án của hệ thống con, như được liệt kê trong các vấn đề mở :

đường dẫn

Cách tốt nhất để sử dụng đường dẫn Win32 trong các ứng dụng POSIX là gì? ý tưởng:

  • dịch //<device>/<path> thành \\.\<device>\<path> (với trường hợp đặc biệt cho ký tự ổ đĩa - //<letter>/<path>=> <letter>:\<path>- và lối thoát đặc biệt //./<raw text>=> \\.\<raw text>. Đường dẫn UNC có thể được chỉ định bằng //unc/<path>) . //các đường dẫn được bảo lưu theo tiêu chuẩn cho hành vi dành riêng cho việc triển khai và //<letter>/cú pháp để thoát các đường dẫn Win32 được sử dụng rộng rãi trong các môi trường tương thích POSIX hiện có

  • heuristic để nhận ra các đường Win32 "trần" như vậy

  • tra cứu case-insensitive cho các đường Win32 và //đường dẫn (không tiêu chuẩn cho phép loại hành vi thực hiện cụ thể cho //đường dẫn?) .

Tôi không chắc nó đủ điều kiện như thế nào vì tôi không chắc nó đã được thực hiện bao nhiêu, nhưng tôi nghĩ đó là một mô tả hữu ích về vấn đề này.

— mikeerv
nguồn
XENIX không có hệ thống con POSIX , Windows có AFAIK. XENIX là một Unix (ban đầu dựa trên Unix V7 mà Microsoft đã mua giấy phép từ AT & T).
— Stéphane Chazelas
1
Rất vui đọc ở đây cũng về hệ thống con interix / Windows POSIX
— Stéphane Chazelas
@ StéphaneChazelas - khá. Tôi gần như muốn thay thế liên kết của mình với nó, nhưng cuối cùng nó chỉ dựa trên một chút ý kiến ​​và không thực sự hoạt động như một tài liệu tham khảo ... nhưng đừng xóa bình luận, làm ơn?
— mikeerv
Trong mọi trường hợp, nó không đề cập đến việc //foo/barxử lý. Tôi chưa tìm thấy bằng chứng mạnh mẽ về hệ thống con Windows POSIX hoặc Interix thực sự đã xử lý chúng cho đến nay.
— Stéphane Chazelas
@ StéphaneChazelas - Tôi không biết nếu nó cực kỳ không phù hợp, hoặc nếu bỏ đi phần tùy chọn chỉ là một sự giám sát, nhưng lsacllệnh MKS sẽ được hiểu \\machinename\driveletter:\pathtrong khi registrylệnh của nó được hiểu là hình thức đó hoặc tùy ý// . Vì bộ MKS là tiền thân của Interix và là thứ mà MS vận chuyển cho các phiên bản 1/2, tôi nghĩ Interix phải chấp nhận cú pháp tương thích cho một điều cơ bản như vậy.
— mikeerv
4

Vào những năm 1980, SEL / Gould có một hệ điều hành Unix có tên UTX-32, tương đương với Solaris; tức là, đường dẫn truy cập từ xa trên máy chủ . Tôi không thể tìm thấy bất kỳ tài liệu nào về nó, vì vậy tôi không biết liệu đây là RFS hay tiến hóa song song (hoặc liệu AT & T//host/path/net/host/pathpathhostlấy trộm mua nó từ Gould).

— Scott
nguồn
Cảm ơn. Bạn có //host/pathtình cờ có bất kỳ tài liệu tham khảo nào về điều đó ( trong UTX-32) không?
— Stéphane Chazelas
Có thể là tôi có một tài liệu sao chép trong một hộp trên gác xép của mình, nhưng không thể - (1) Tôi không nhớ mình từng có nhiều tài liệu (tôi nhớ một cuộc họp ngắn năm phút); (2) ngay cả khi tôi có nó, tôi có thể không mang nó về nhà; (3) ngay cả khi tôi mang nó về nhà, có lẽ tôi đã ném nó ra một thời gian trong 30 năm qua; và (4) ngay cả khi tôi vẫn còn có nó, có lẽ tôi sẽ không thể tìm thấy nó. Ồ, cũng vậy (0) Tôi đã dành năm phút để Googling nó (vô ích) trước khi tôi đăng câu trả lời của mình.
— Scott
4

Tôi có một bộ nhớ mơ hồ rằng //host/pathký hiệu đã được sử dụng trên AT & T SysV.3 như là một phần của việc thực hiện Chia sẻ tệp từ xa RFS của nó . Điều này cuối cùng đã bị bỏ rơi vào khoảng thời gian SysV.4 được phát hành để ủng hộ NFS đơn giản nhưng phổ biến hơn từ Sun microsystems.

Tuy nhiên, tôi không thể tìm thấy bất kỳ tài liệu tham khảo cụ thể nào về cú pháp và tài liệu tôi vừa xem xét dường như chỉ ra rằng ý tưởng của người dùng chỉ định rõ ràng tên máy chủ từ xa sẽ trái ngược với nguyên tắc thiết kế độc lập vị trí.

Tài liệu tham khảo 1. RFS Tổng quan kiến ​​trúc

— roaima
nguồn
3
Founf này về RFS. Tôi không thể tìm thấy tài liệu tham khảo //host/path. Nó dường như ngụ ý rằng các hệ thống tập tin mạng phải được gắn kết rõ ràng.
— Stéphane Chazelas
Cảm ơn bạn đã nhắc nhở. Đây là một trong những phần của "tài liệu tôi đã xem xét", vì vậy tôi sẽ thêm một liên kết đến nó nếu bạn không phiền. Tôi vẫn còn hoang mang về điều này; nó có thể đến với tôi vào ngày hôm sau.
— roaima
4

POSIX nêu trong Cơ sở lý luận cho A.4.12 Đoạn giải quyết tên đường dẫn 9 và 10:

Trong một số hệ thống nối mạng, cấu trúc /../hostname/ được sử dụng để chỉ thư mục gốc của máy chủ khác và POSIX.1 cho phép hành vi này.

Các hệ thống nối mạng khác sử dụng cấu trúc // tên máy chủ cho cùng một mục đích; đó là, một dấu gạch chéo ban đầu được sử dụng.

Điều này dường như xác nhận điều đó //có nghĩa là "mạng gốc" hoặc ít nhất đó là ý tưởng khi quy tắc được đưa vào POSIX.

Các quy tắc tuân theo để loại bỏ bất kỳ ý nghĩa nào //ở giữa một đường dẫn cho một /Pathname đã bắt đầu:

... vì các chuỗi không dẫn đầu của hai hoặc nhiều ký tự <slash>
được coi là một <slash>, ...

Tất nhiên, một //Pathname đã bắt đầu có thể mở rộng hoặc thay đổi việc sử dụng //bên trong Pathname (không phải lúc bắt đầu). POSIX.1 cho phép điều này. Điều cuối cùng này xác nhận rằng chỉ //được phép là ở đầu Tên đường dẫn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.