Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

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

It is said that the filename of a file is a pointer pointing to the inode of the file. Before knowing that, I thought it was the pathname of a file that does that job.

I am not sure how a pathname and a filename are defined in Unix. For example, is it correct that /home/tim/tim.pdf is the pathname of the file with file name tim.pdf.

I wonder what the difference between the filename and the pathname of a file? Thanks.

share|improve this question
What is the "pathname of the file"? – Joseph R. Jul 28 '14 at 1:59
updated. @JosephR. – Tim Jul 28 '14 at 2:02
"It is said that the filename of a file is a pointer pointing to the inode of the file" - Where is this stated please? – Warwick Jul 28 '14 at 2:18
up vote 1 down vote accepted

In POSIX terminology, a filename is the name of a directory entry. It consists of a non-empty sequence of bytes other than / or null. The term “pathname component” is synonymous with “filename”. A pathname is a string that can contain any non-null byte and that designates a way to locate a file. A pathname consists of a series of filenames, in which all but the last refer to a directory. Pathname resolution is the process of locating a file from a pathname.

For example, /home/tim/tim.pdf is a pathname. The last component of that pathname tim.pdf is a filename; it is the name of an entry in the directory whose pathname is /home/tim. The filename tim is itself the name of an entry in the directory whose pathname is /home; this file happens to be a directory. tim.pdf is also a pathname: any filename is a pathname that happens to have a single component and designates the file with that name in the current directory.

/ is a pathname that refers to the root directory. . is a filename that exists in every directory and refers to that directory itself. . is a pathname which happens to contain a single component and refers to the current directory.

You can think of a filename as a pointer within a directory to an inode that is a file in that directory. A pathname is a specification of where to find an inode. Each component of a pathname is a filename that points to an inode in the directory reached so far (if the file exists). Pathnames either start at the root directory (if they are absolute pathnames, beginning with /) or at the current directory (if they are relative pathnames, not beginning with /).

Note that in many texts, the word “filename” (or “file name”) is used to mean what POSIX calls a pathname.

share|improve this answer
So /home/tim/tim.pdf is pathname, and tim.pdf is not pathname? I think filename is only special case of pathname. And why in 4.6 Filenames section, they use pathname: pubs.opengroup.org/onlinepubs/009604499/basedefs/… – cuonglm Jul 29 '14 at 1:22
@Gnouc tim.pdf is a pathname. Any filename is a pathname. – Gilles Jul 29 '14 at 1:23
So Why did you say my answer is wrong? – cuonglm Jul 29 '14 at 1:24
@Gnouc You stated that “they use filename and pathname interchangeable”, which is not at all the case. Any filename is also a pathname, but the converse is not true. – Gilles Jul 29 '14 at 1:39
I also said in section Filenames only. – cuonglm Jul 29 '14 at 1:44

A directory contains a list of filename ⇒ inode mappings. Your directory /home/tim includes an entry with filename tim.pdf, pointing at (say) inode 1234.

How do we get at that directory? Well, a directory is really a special kind of file that contains those entries. We can find it the same way we find other files, by looking in its parent: /home will have an entry with filename tim that points to the inode of the directory. In turn, we can find /home by looking in its parent, /.

/ is the root, and it's a little bit more special. The system knows how to get to it directly, because it has no parent.

The name of a file is the local name it has in its directory: tim.pdf. The path of a file describes how you get to it from the root: /home/tim/tim.pdf. If you like, you can think of that as a set of instructions: first find /, then find home inside that, then tim, then finally tim.pdf that you were looking for.

Resolving any path is in effect a recursive algorithm with this pseudocode:

inode find_file(inode where_i_am, string[] remaining_path):
    if remaining_path is empty:
         # Nothing more to look at - we've found the file!
         return where_i_am
    current_item = remaining_path[0]
    rest_of_path = remaining_path[1..]
    for entry in directory_entries(where_i_am):
        if entry.filename == current_item:
            return find_file(entry.inode, rest_of_path)
    return file not found

We'd find your file with:

find_file(inode_of_root, ["home", "tim", "tim.pdf"])

There are a few cases where things get slightly more complicated, which the pseudocode doesn't cover. One of those is mounts: when you mount another partition at, say, /home, the system remembers that when it goes to /home it should shift over to that other partition, and start looking for tim in the root of that file system instead. The new file system will have its own set of inodes, so you actually need to know both the inode and the device to access a file's data. A real structure actually includes both.

Symbolic links tell the system to go and look up some other path at this point, and then continue on searching from that new location.

Another case is hard links (your old friend). An ordinary file inode can have arbitrarily many hard links to it. You could make a link with ln tim.pdf pdf.tim, which would have the same contents and live at the same point on disk. There would be a separate directory entry pdf.tim that pointed at the same inode 1234 as the entry for tim.pdf. Our algorithm works just fine for this case: a hard link to a file is exactly the same as the original file, and we don't need to distinguish it at all in any way. The fact that a hard link is just another name for an inode is why you can't make hard links across file systems.

Yet another is the special entries . and ... These are (often, but filesystem-dependent) real directory entries. They're essentially hard links to the directory itself and to its parent. Our algorithm deals with that too. There's an interesting case that comes up with mounts: because the underlying filesystem doesn't know where it would be mounted, it couldn't have the right .. entry. To deal with that the system essentially cheats and shows the .. entry from the directory on the parent device, rather than from the root of the mounted file system.

So when you're looking at things from the perspective of inodes like this then:

  • A file name is a name a particular inode is called inside a particular directory.
  • A path is some instructions for how to reach an inode from a known point.
share|improve this answer
At least in Linux, root's parent is itself. – cuonglm Jul 28 '14 at 8:47

In General, pathname and filenames are the same. First, read some rules for filenames from POSIX documentation:

4.6 Filenames

For a filename to be portable across implementations conforming to IEEE Std 1003.1-2001, it shall consist only of the portable filename character set as defined in Portable Filename Character Set.

The hyphen character shall not be used as the first character of a portable filename. Uppercase and lowercase letters shall retain their unique identities between conforming implementations. In the case of a portable pathname, the slash character may also be used.

You can see, in this section, they use filename and pathname interchangeable.

There also difference between them in process called Pathname Resolution:

4.11 Pathname Resolution

Pathname resolution is performed for a process to resolve a pathname to a particular file in a file hierarchy. There may be multiple pathnames that resolve to the same file.

Each filename in the pathname is located in the directory specified by its predecessor (for example, in the pathname fragment a/b, file b is located in directory a). Pathname resolution shall fail if this cannot be accomplished. If the pathname begins with a slash, the predecessor of the first filename in the pathname shall be taken to be the root directory of the process (such pathnames are referred to as "absolute pathnames"). If the pathname does not begin with a slash, the predecessor of the first filename of the pathname shall be taken to be the current working directory of the process (such pathnames are referred to as "relative pathnames").

pathname is resolved to file, and filename is located in the directory specified by its predecessor.


share|improve this answer
These citations are very relevant, but your commentary is completely wrong. Filename and pathname are not at all interchangeable! POSIX uses them for different concepts. – Gilles Jul 28 '14 at 22:08

Your Answer


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.