Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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).

share|improve this question
1  
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 at 12:14
1  
standard (pubs.opengroup.org/onlinepubs/009695399/basedefs/…) 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 : 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 at 16:10
3  
@DevSolar: really interresting (and surprising), but we should stick to POSIX only, as out of POSIX anything is possible ^^ – Olivier Dulac Jan 20 at 16:45
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 at 23:30

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

share|improve this answer
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 at 2:20
    
Windows itself implements the POSIX API... how does that handle a leading double slash? – Kevin Jan 24 at 1: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 at 2:13
    
@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 at 9:34
    
@AlexGittemeier. Yes, you'll notice it's actually used in this answer ;-). – Stéphane Chazelas Jan 24 at 9:35

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

share|improve this answer

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.

share|improve this answer
1  
Corroborated by this usenet discussion – Stéphane Chazelas Jan 22 at 16:41
    
@StéphaneChazelas I believe that this link to Usenet discussion is better. The one you choose has Domain/OS but not Utek. Or the next message (from yours) – BinaryZebra Jan 23 at 12:59
    
from the author (working at Tektronix) of the public domain RFS implementation that made it to BSDs‌​, there were both a DFS and RFS developed there. – Stéphane Chazelas Jan 25 at 15:47
    
Tektronix/BSD RFS implementations apparently mounted remote file systems on regular files to avoid find for instance traverse the mount point. The author explicitly rules-out //foo/bar (or the Newcastle connection's /../foo/bar) there – Stéphane Chazelas Jan 25 at 15:54
    

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.

share|improve this answer
    
I think the grawity guy is a major arch Linux dev. – mikeserv Jan 20 at 14:14

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.

share|improve this answer

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).

share|improve this answer
    
Thanks. Would you happen to have any reference on that (//host/path in UTX-32), by any chance? – Stéphane Chazelas Jan 22 at 9: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 at 9:48

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

share|improve this answer
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 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. – roaima Jan 20 at 21:07

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:

  • translate //<device>/<path> into \\.\<device>\<path> (with a special case for drive letters - //<letter>/<path> => <letter>:\<path> - and the special escape //./<raw text> => \\.\<raw text>. UNC paths can be specified with //unc/<path>). // paths are reserved by the standard for implementation-specific behavior, and the //<letter>/ syntax to escape Win32 paths is widely used in existing POSIX compatibility environments

  • heuristics to recognize "bare" Win32 paths as such

  • case-insensitive lookup for Win32 paths and // paths (does the standard allow this kind of implementation-specific behavior for // paths?).

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.

share|improve this answer
    
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 at 10:32
1  
Nice read here as well about interix/Windows POSIX subsystem – Stéphane Chazelas Jan 26 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 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 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 at 11:45

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.