Take the 2-minute tour ×
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.

Can anybody point to a man page or specification that defines the Universal Naming Convention (UNC)? I'm looking for the original source of the idea

share|improve this question
1  
"is often described as originating in Unix." - could you link to any such description? –  Mat Dec 3 '12 at 10:47
    
pcmag.com/encyclopedia_term/0,1237,t=UNC&i=53398,00.asp And yes, many people believe it's an MS invention. Memories differ, that's why I'm asking this question. –  Isaac Rabinovitch Dec 3 '12 at 18:27
    
@MichaelMrozek Thanks, good edit. –  Isaac Rabinovitch Dec 4 '12 at 5:53

3 Answers 3

As I remember it (and Wikipedia concurs), UNC is a term that originates from Microsoft Windows.

In fact, I don't think I've ever heard before that it originated in UNIX.

Furthermore, I can't find any references to UNC in either POSIX or any RFC. Every reference I have found elsewhere is in relation to Windows. And the singular reference you cite referring to UNIX as the origin also cites Windows as the origin.

There's a game they play on Sesame Street...

One of these things is not like the others...

This lack of reference is the best evidence I can find that leads to the conclusion that the term did not originate in UNIX. Granted, absence of evidence is not evidence of absence. But it seems more probable that there's an error in PC Mag's definition than that there's a gaping omission in the POSIX specification and that in all this time there was never an RFC defining UNC, much less even mentioning it.

But I'll gladly down vote my own post if I'm wrong.

share|improve this answer
    
I've expanded my answer with respect to the POSIX specification and RFC's. Granted, absence of evidence is not evidence of absence. However it does heavily weigh the probability factor. –  bahamat Dec 3 '12 at 19:59
    
I'd say the exact opposite. There is no evidence that stars guide our destiny. There's more evidence to the contrary. If the evidence contradicts your belief then it's time to change your belief. –  bahamat Dec 3 '12 at 20:04
    
And W3C can't decide for URL or URI either. –  bahamat Dec 3 '12 at 20:06
    
let us continue this discussion in chat –  bahamat Dec 3 '12 at 20:08
1  
Actually, there is a mention in the POSIX rationale (not by name), which strongly suggests a non-Unix origin. –  Gilles Dec 3 '12 at 23:07

The \\hostname\directory\… syntax does not (directly) originate in the Unix world, as far as I know. I do not know its origin; from what I can find on the web, UNC does not originate from Netware, nor does it come from Plan9 or VMS. By 1995, it was a native feature of both Windows NT and OS/2. OS/2 had the concept as far back as May 1993, which predates the first release of Windows NT. It may have originated from LAN Manager (developed wby Microsoft on top of IBM's OS/2, at a time when IBM and Microsoft were sharing OS/2 code).

An early mention of UNC is in US patent 5363487 (bottom of column 29, an fig. 9), filed in 1989 by Microsoft (thanks to John Summerfield for the reference). A later patent, US 5341499 (by IBM), affirms that “the Universal Naming Convention was jointly invented by IBM and Microsoft for use in their jointly developed Local Area Network (LAN) software products”. This is very likely to mean LAN Manager.

There is a smidgen of Unix inspiration in the UNC, in that it removes the need for drive letters, allowing network drives to be referenced directly instead of having to first assign a drive letter (and make sure not to have a conflict, with only 26 or 32 drive letters). But Unix used a more flexible mount point system from almost day 1, where a network drive can be attached at any point in the directory hierarchy and not at the top.

Unix acknowledges the UNC in that it allows // at the beginning of a path to be treated specially. From the POSIX rationale (A.4.11 Pathname Resolution):

Other networked systems use the construct //hostname for the same purpose.

Note that the rationale mentions “other systems”, not “historical usage”. This strongly implies that //hostname/directory is not historical usage in the Unix world, but usage in some other system where POSIX implementations might exist.

share|improve this answer
    
Sigh. I think I need to rewrite the question so that folks will stop interpreting this as an invitation to argue about who invented UNC. I'm looking for information on the source of the idea. Thanks for the patent link, though. I disagree with your conclusions, but this is not the place to argue about that. –  Isaac Rabinovitch Dec 4 '12 at 2:06
    
@IsaacRabinovitch The idea is closely tied with the notation. It's a product of the preexisting syntax for DOS paths (letter colon backslash directory backslash file) modified to accommodate remote paths in a simple way (simpler than the Unix syntax which is more general (so less easy to parse) and requires mounting before use — a problem which the Unix world solved through automounting). –  Gilles Dec 4 '12 at 8:46
    
Nice theory. But I'm looking for documents. –  Isaac Rabinovitch Dec 4 '12 at 20:07
    
@IsaacRabinovitch I found an explicit acknowledgement in another patent. It is from LAN Manager (at least in its precise form of double-directory-separator, hostname, absolute-remote-path). –  Gilles Dec 4 '12 at 20:20
    
Yep, sort of thing I'm looking for. Patent #? –  Isaac Rabinovitch Dec 5 '12 at 4:06

Extending local file systems to be part of a larger network via '//hostname/directory/filename' notation dates back to at least Apollo/DomainOS (1981), though it wasn't called UNC at the time. Apollo/DomainOS could be used with SysV and BSD Unix environments.

See chapter 1 in http://www.typewritten.org/Articles/Apollo/005488-02.pdf

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.