125

Throughout the POSIX specification, there's provision (1, 2, 3...) to allow implementations to treat a path starting with two / specially.

A POSIX application (an application written to the POSIX specification to be portable to all POSIX compliant systems) cannot assume that //foo/bar is the same as /foo/bar (though they can assume that ///foo/bar is the same as /foo/bar).

Now what are those POSIX systems (historical and still maintained) that treat //foo specially? I believed (I've now been proven wrong) that POSIX provision was pushed by Microsoft for their Unix variant (XENIX) and possibly Windows POSIX layer (can anyone confirm that?).

It is used by Cygwin which also is a POSIX-like layer for Microsoft Windows. Are there any non-Microsoft Windows systems? OpenVMS?

On systems where //foo/bar is special, what is it used for? //host/path for network file systems access? Virtual file systems?

Do some applications running on Unix-likes —if not the system's API— treat //foo/bar paths specially (in contexts where they otherwise treat /foo/bar as the path on the filesystem)?

Edit, I've since asked a question on the austin-group mailing list about the origin of //foo/bar handling in the spec, and the discussion is an interesting read (from an archaeology point of view at least).

Stéphane Chazelas
  • 544,893
  • 1
    Related: Official Description UNC (Universal Naming Convention) – Stéphane Chazelas Jan 20 '16 at 11:55
  • already, ls -ld // displays d..... // instead of d..... / : is it one of the side effect you are looking for ? – Olivier Dulac Jan 20 '16 at 12:08
  • 1
    @OlivierDulac, No. ls -ld /// would also display ///, ls just displays the file it is being told to display as it was given. I'm looking for systems or applications that treat //foo/var specially (not as a path on the filesystem) like Cygwin does. – Stéphane Chazelas Jan 20 '16 at 12:14
  • on my Linux box, /boot/grub and //boot/grub and ///boot/grub and //////////////////////////////////////////////////////////////////////////////////boot/grub are all the same according to a range of applications. – cat Jan 20 '16 at 12:54
  • 1
    standard (http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11) says, as you mentionned, "A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner" (more than 2 resolves to 1 /). An exemple found on the net : http://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.... not exactly unix, though ^^). – Olivier Dulac Jan 20 '16 at 16:10
  • I don't know about POSIX, but on the AmigaOS, cd / (or just /) is what cd .. is for Unix. So AmigaOS would interpret /foo/bar as Unix would cd ../foo/bar, and //foo/bar as Unix would cd ../../foo/bar. (The filesystem root would be :.) – DevSolar Jan 20 '16 at 16:20
  • 4
    @DevSolar: really interresting (and surprising), but we should stick to POSIX only, as out of POSIX anything is possible ^^ – Olivier Dulac Jan 20 '16 at 16:45
  • On Windows a path starting with \\ is a UNC path, but Windows doesn't follow POSIX (nor claim to). – user253751 Jan 20 '16 at 19:11
  • if ///foo/bar is the same as /foo/bar then why on Linux, chromium would open a image file as file:///home/edward/Pictures/arch-wallpaper.png ? (note the starting three slashes) – Alex Jones Jan 20 '16 at 22:28
  • 2
    @edwardtorvalds because the first bit is the URL: file://, alike to http:// and such. On chrome here at work a windows UNC path that I have open now is file:////$MACHINE/$SHARENAME/index.html (although for some reason it also understands file://$MACHINE/...) – admalledd Jan 20 '16 at 23:30
  • related http://stackoverflow.com/questions/26469921/what-is-the-significance-of-in-bash – ren Jan 22 '16 at 11:27
  • As I remember, on Solaris //foo meant accessing some form of remote filestore, global to the network. – vonbrand Jan 25 '16 at 17:58

9 Answers9

103

This is a compilation and index of the answers given so far. This post is community wiki, it can be edited by anybody with 100+ reputation and nobody gets reputation from it. Feel free to post your own answer and add a link to it in here (or wait for me to do it). Ideally, this answer should just be a summary (with short entries while individual other answers would have the details).

Currently actively maintained systems:

Defunct systems

Applications that treat //foo/bar specially for paths

gps
  • 103
Stéphane Chazelas
  • 544,893
  • 3
    Using the // namespace was proposed by some Linux kernel developers for Reiser4's metadata facilities, but I don't think this proposal ever gained traction within Namesys, nor was it ever implemented. – Jörg W Mittag Jan 21 '16 at 02:20
  • Windows itself implements the POSIX API... how does that handle a leading double slash? – Kevin Jan 24 '16 at 01:13
  • 1
    We can add that on the web, resources starting with a double slash define a different root than the single slash does. – Alex Gittemeier Jan 24 '16 at 02:13
  • 1
    @Kevin, yes I also believe it (see the question), though I think it was an optional component and only on some variants of Windows and now discontinued. If you have more details, please add an answer. – Stéphane Chazelas Jan 24 '16 at 09:34
  • @AlexGittemeier. Yes, you'll notice it's actually used in this answer ;-). – Stéphane Chazelas Jan 24 '16 at 09:35
  • Is UWIN really "actively maintained"? Where? – jrw32982 Jan 27 '16 at 05:41
  • @jrw32982, it's true the future of uwin like that of ksh93 is uncertain, but it may be a bit premature to call them dead yet. – Stéphane Chazelas Jan 27 '16 at 12:13
  • @WouterVerhelst, samba accepts //foo/bar specifications for CIFS shares, not as file paths, not in contexts where it also accepts normal paths. There's a deleted answer that mentioned the same for mount -t cifs (which does invoke some samba utility). – Stéphane Chazelas Feb 11 '16 at 10:09
  • @Gilles, I've rolled back your emacs edit as the Q&A is about where file paths that start with // receive a special treatment as allowed by POSIX. – Stéphane Chazelas Oct 26 '17 at 20:57
  • @Kevin Windows has supported / as alternative to \ for a long time (I have no idea how long, but must've been many many years now), which includes UNC paths and their \ (or //, respectively) prefix, which fits conveniently with the POSIX spec. Under cmd.exe a path including /s needs to be enclosed in double quotes to prevent interception and interpretation as switches, but otherwise dir "//foo/bar" et al work fine. – blubberdiblub Apr 06 '23 at 05:48
16

Do some applications running on Unix-likes —if not the system's API— treat //foo/bar Paths specially?

I am aware of Perforce which uses //depot/A/B/C/D Paths to refer to the Depot. Perforce also supports //Client/C/D Paths, when the Client is pointing to //depot/A/B/. Here, local FileSystem may not have these Paths.

p4 filelog //depot/A/B/C/D will show the history of that file, even though there is no file /depot/A/B/C/D.

p4 filelog C/D will also show the history of that file, if executed from appropriate Directory.

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

Stéphane Chazelas
  • 544,893
Prem
  • 3,342
13

Several decades ago, Tektronix Utek (BSD 4.2 based Unix, first on National Semiconductors 32016 CPUs then Motorola 68020s) was providing something called DFS (distributed file system) under which //foo/bar was referring to the /bar file on the foo dfs server. It was later obsoleted by Sun's NFS.

Unfortunately, I haven't reference yet to back that but I might eventually find some Utek documentation in my cellar and update this reply.

jlliagre
  • 61,204
8

Following the lead from this answer. And reading page 2-15 from the manual from Bitsavers (thanks @grawity).

Shared Data
The second design principle of the Domain/OS distributed file system, sharing by default, implies a global uniform name space. The name space of the distributed file system appears to users like that of a giant timesharing file system. It is a traditional UNIX hierarchical name space, except that absolute pathnames can begin with the name of the network root (called //). It is also possible to express pathnames relative to the root of the local node (the / directory).

There is also an older manual from with a "First Printing: July, 1985". On page 1-4:

The double slashes (//) in Figure 1-2 represent the top level of the naming tree, the network root directory.

So, we have confirmation that Domain/OS from Apollo used // for network root.

Community
  • 1
5

The ReactOS project - which is a free and open-source implementation of the NT kernel and related APIs - has apparently undertaken to also implement its own Interix-like POSIX subsystem (though MS's original OS/2 subsystem is also mentioned in context, no mention is made of a ReactOS analog).

Though the efforts so far have been small, fork() is apparently a reality. Here is a an excerpt from the subsystem's project page, as listed under open issues:

paths

What's the best way to use Win32 paths in POSIX applications? ideas:

<ul>
<li><p>translate <code>//&lt;device&gt;/&lt;path</code>> into <code>\\.\&lt;device&gt;\&lt;path&gt;</code> <em>(with a special case for drive letters - <code>//&lt;letter&gt;/&lt;path&gt;</code> => <code>&lt;letter&gt;:\&lt;path&gt;</code> - and the special escape <code>//./&lt;raw text&gt;</code> => <code>\\.\&lt;raw text&gt;</code>. UNC paths can be specified with <code>//unc/&lt;path&gt;</code>)</em>. <code>//</code> paths are reserved by the standard for implementation-specific behavior, and the <code>//&lt;letter&gt;/</code> syntax to escape Win32 paths is widely used in existing POSIX compatibility environments</p></li>
<li><p>heuristics to recognize "bare" Win32 paths as such</p></li>
<li><p>case-insensitive lookup for Win32 paths and <code>//</code> paths <em>(does the standard allow this kind of implementation-specific behavior for <code>//</code> paths?)</em>. </p></li>
</ul>

I'm not sure how that qualifies as I am not sure how much of it has been implemented, but I thought it was a usefully interesting description of the problem.

mikeserv
  • 58,310
  • XENIX didn't have a POSIX subsystem, Windows had AFAIK. XENIX was a Unix (initially based on Unix V7 which Microsoft bought a license of from AT&T). – Stéphane Chazelas Jan 26 '16 at 10:32
  • 1
    Nice read here as well about interix/Windows POSIX subsystem – Stéphane Chazelas Jan 26 '16 at 10:39
  • @StéphaneChazelas - quite. I almost want to replace my link with it, but it is a little opinion-based at the end, and doesn't really work as a reference... but don't delete the comment, please? – mikeserv Jan 26 '16 at 10:50
  • In any case, it doesn't mention //foo/bar handling. I've not found strong evidence the Windows POSIX subsystem or Interix actually handled them so far. – Stéphane Chazelas Jan 26 '16 at 11:25
  • @StéphaneChazelas - I dunno if it was just extremely incosistent, or if leaving out the optionally part was just an oversight, but the MKS lsacl command is spec'd to understand \\machinename\driveletter:\path while its registry command was spec'd to understand that form or optionally // either way. As the MKS kit was the predecessor to Interix and was what MS shipped for versions 1/2 I would think Interix must have accepted compatible syntax for such a basic thing. – mikeserv Jan 26 '16 at 11:45
  • @StéphaneChazelas - and there is: *Do MKS Toolkit porting products support pipe()? What are named pipes? Yes, MKS Toolkit porting products support pipe(). Win32 defines a named pipe, which is entirely different from a UNIX FIFO. Win32 named pipes let multiple clients establish bidirectional communications to a single server application, each with its own pair of buffers. The clients and server can be on different machines. You can access Win32 named pipes with open("//server/pipe/<pipe name>").* – mikeserv Jan 26 '16 at 12:22
  • @StéphaneChazelas - according to this the lack of a mention of // for lsacl must have been just an oversight. – mikeserv Jan 26 '16 at 12:35
5

Another application: Blender treats a leading // as a reference to the project directory (the directory in which the .blend file is saved). Here's the relevant manual page.

This is true for non-Unix-like operating systems (i.e., Windows) as well.

wchargin
  • 1,091
4

I have a vague memory that the //host/path notation was used on AT&T SysV.3 as part of its RFS Remote File Sharing implementation. This was eventually abandoned around the time SysV.4 was released in favour of the simpler but more popular NFS from Sun Microsystems.

However, I cannot find any concrete references to the syntax, and the documentation I have reviewed just now seems to indicate that the idea of the user explicitly specifying a remote hostname would have been opposed to the design principle of location independence.

References 1. RFS Architectural overview

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • 3
    Founf this about RFS. I can't find references to //host/path. It seems to imply that network file systems have to be mounted explicitly. – Stéphane Chazelas Jan 20 '16 at 21:01
  • Thank you for the reminder. This is one of the pieces of "documentation I have reviewed", so I'll add a link to it if you don't mind. I'm still puzzling over this; it may come to me in the next day or so. – Chris Davies Jan 20 '16 at 21:07
4

In the 1980s, SEL/Gould had a Unix operating system called UTX-32 in which //host/path was equivalent to /net/host/path in Solaris; i.e., remotely access path path on host host.  I can't find any documentation on it, so I don't know whether this was RFS or parallel evolution (or whether AT&T stole acquired it from Gould).

Scott - Слава Україні
  • 10,519
  • Thanks. Would you happen to have any reference on that (//host/path in UTX-32), by any chance? – Stéphane Chazelas Jan 22 '16 at 09:16
  • It's possible that I have a hard-copy document in a box in my attic, but unlikely — (1) I don't recall ever having a lot of documentation (I remember a five-minute oral briefing); (2) even if I had it, I might not have taken it home; (3) even if I took it home, I probably threw it out some time in the past 30 years; and (4) even if I still have it, I probably won't be able to find it. Oh, also (0) I spent five minutes Googling it (to no avail) before I posted my answer. – Scott - Слава Україні Jan 22 '16 at 09:48
4

POSIX states in the Rationale for A.4.12 Pathname Resolution Paragraphs 9 and 10:

In some networked systems the construction /../hostname/ is used to refer to the root directory of another host, and POSIX.1 permits this behavior.

Other networked systems use the construct //hostname for the same purpose; that is, a double initial slash is used.

This seems to confirm that // means "network root", or at least that that was the idea when the rule was included in POSIX.

Rules follow to remove any meaning of // in the middle of a path for an / started Pathname:

... since non-leading sequences of two or more <slash> characters
are treated as a single <slash>, ...

Of course, a // started Pathname may expand or change the use of // inside a Pathname (not at the start). POSIX.1 allows this. This last confirms that the only // allowed are at the beginning of a Pathname.