3 Answers
3

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:

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.

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.

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.