This is probably a very poorly worded question, but the taxonomy of this question is what I'm looking for (so unfortunately at this point I can't help it).

Here is my question.

We don't walk around calling the file system representation for Centos "Centos File Paths", likewise we don't call the file system in Ubuntu "Ubuntu File Paths" or even "Linux File Paths" - I typically see these referred to as NFS paths (whether this is correct or not).

I do hear Windows users refer to the file system representation (with drive letters) as "Windows file paths". So I guess I'm asking "What exactly is a Windows File path"? By this, I mean what are the underlying concepts and protocols that govern what a Windows file path is.

For further clarity, here are some examples. To my understanding, what I refer to as a NFS path (whether this is correct or incorrect) looks like this:


where each level/dir is divided by /

My naive taxonomy for "Windows path" looks something like:


So by default, when I jump onto one of the various Linux variants I use (Centos, Ubuntu) I usually refer to this as an NFS path. When I hop onto Windows, I call it a "Windows Path". I realize there are protocols and standards which probably govern this file system mapping (e.g. what maps c:\some-dir to sections of a disk), and Google has pointed me to CIFS/SMB described here: http://en.wikipedia.org/wiki/Cifs

But this seems to describe Windows network paths. I also saw the "drive naming scheme" here - http://en.wikipedia.org/wiki/DOS#Drive_naming_scheme - but this doesn't really answer my question. When I jump on my Windows machine, what exactly makes a Windows path? Specifically, when I specify c:\some-dir\some-child-dir, what protocols and standards are being used by the operating system to point this address to part of my hard-drive? Let's assume we're talking about Windows 7 (although I'd also be interested to know if Windows 7 does this differently from other versions of Windows).

I realize this is probably noob question and the answer is probably very easy to find with the correct keywords, but the frustration of not knowing is starting to get to me.

No "Just Google it" answers please - I have done this extensively and it just seems to raise further questions. I'm looking for a technical explanation here.

closed as not a real question by Iain, Scott Pack, ewwhite, Jim B, mailq Dec 4 '11 at 12:01

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.

locked by HopelessN00b Jan 21 '15 at 22:21

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Read more about locked posts here.

  • "Just Google it" is frowned upon here. What is your question by the way ? – Iain Dec 3 '11 at 14:51
  • Are you asking how Windows and NTFS decide that X file is on Y sector on a given HDD? – Driftpeasant Dec 3 '11 at 19:27
  • @Iain "What is your question by the way ?" - I understand what you're getting at, but if I understood that I wouldn't be asking the question. Driftpeasant - sort of. In terms of both of your questions, I guess that I would argue that we don't walk around calling the file system representation for Centos "Centos File Paths", or "Ubuntu File Paths" or even "Linux File Paths", but I do hear Windows users refer to the file system representation (with drive letters) as "Windows file paths". So I guess I'm asking "What the heck is a Windows File path". – Aaron Newton Dec 4 '11 at 5:46
  • Can I inquire as to why this is tagged as "Not a real question"? I understand that it was convoluted, but I feel I have provided adequate examples and follow up comments. I also explained the paradox whereby the question was convoluted as I didn't understand the taxonomy of my own question. I've also noticed I was marked down - which I guess is fair - but I still think this is a valid and important question. Would you please reconsider as I feel this question and its readers could benefit from further discussion on this topic. – Aaron Newton Dec 4 '11 at 23:38
  • Further to my comments above, I have edited my question. I would now argue that it is very much in the form of a question, rather than being a statement as it may have been previously. Can you please reconsider the closure, as even though I got an answer I feel that more discussion may be required. – Aaron Newton Dec 4 '11 at 23:55

Just about every modern system uses a filesystem supporting a hierarchical structure -- some base level, with folders containing more folders (and so on), some of them with files in them.

The choice of the character used in the interface to tell you where you are is pretty arbitrary; UNIX-based systems use forward slash (/), DOS-derived ones used backslash (\) -- MSDN has some background on that choice -- while pre-OSX Macs used colon (:)

DOS (and descendents, up until NT) gave all the physical drive devices (and things that fake them) single-letter identifiers. Originally there was room for 2 floppy drives (A: and B:), so the hard drive became C:, and stayed that way by tradition (to the point that a shocking number of programs break if you change your boot drive's letter.)

In NT, they did away with most of the behind-the-scenes requirements for having the drive be C:, and added the ability to mount another physical drive as a directory under C:. This puts it more in line with the UNIX way of things: the boot drive is mounted as '/', and various other drives can be mounted as folders underneath it (/home, /usr, /tmp, whatever you like).

When DOS discovered networks, they got rid of drive letters for remote devices, getting you a UNC-style path: \servername\share\folder\file.txt. The share is just a name for the base directory on the server side, and it's pretty typical for the share name to match the name of the top-level directory of the share, but not a requirement.

When you stay UNIX-to-UNIX or Windows-to-Windows, it's simple, just keep slash-versus-backslash the same everywhere, and you're set. When you cross over, things get messy. Most programs stick with the syntax for the platform they're running on, even when they are (likely unknowingly) accessing something from the other platform. Some apps -- specifically written for cross-platform compatibility or attempts at user-friendly ness -- like their inputs in the intended format for the other platform. This gets messy: UNIX shells use backslash as the escape char; you need to type '\\' to get a single backslash sent as input to a UNIX command as a command-line option.

All that, of course, is mostly user-interface stuff. Behind the sceens, a file is really identified by (basically) a number (UNIX systems call it an inode), and the file system is responsible for tracking which names (possibly multiple, in different directories, in the case of hard links) map to the same inode, and which disk sectors are the content of the same inode).

  • this is a good and informed answer, so I have marked it as the "correct answer". The beef of the answer here seems to be that "The choice of the character used in the interface to tell you where you are is pretty arbitrary", so unless someone can indicate that there is some non-trivial reason or protocol behind lettered Windows paths in the form c:\some-path, I'm going to accept that this is the correct answer. UNC also seems to be a good way to describe "Windows Paths" - en.wikipedia.org/wiki/… – Aaron Newton Dec 4 '11 at 5:58
  • Side note: PowwerShell in Windows accepts Unix-style '/' directory delimiters now. I don't think Windows will ever change natively, but certain APIs and frameworks are becoming agnostic. – Chris S Dec 6 '11 at 15:33
  • @ChrisS The good old cd accepts the forward-slash notation for directory paths. I believe it has done so since Windows NT. – the-wabbit Jul 23 '12 at 23:12

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