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

  • 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. Jan 20, 2016 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 ^^). Jan 20, 2016 at 16:10
  • 4
    @DevSolar: really interresting (and surprising), but we should stick to POSIX only, as out of POSIX anything is possible ^^ Jan 20, 2016 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, 2016 at 23:30

9 Answers 9


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

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


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.


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.


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:


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.

  • 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). Jan 26, 2016 at 10:32
  • 1
    Nice read here as well about interix/Windows POSIX subsystem Jan 26, 2016 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, 2016 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. Jan 26, 2016 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, 2016 at 11:45

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.


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

  • Thanks. Would you happen to have any reference on that (//host/path in UTX-32), by any chance? Jan 22, 2016 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. Jan 22, 2016 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

  • 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. Jan 20, 2016 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. Jan 20, 2016 at 21:07

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.

  • I don’t understand the last paragraph. It seems to be saying that //foo/bar can be different from //foo//bar. Is that what it means? Is there any reference to support that? May 17, 2022 at 1:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .