Both asked questions are in fact the question: "How
path_resolution works?", so just look at the whole process from this point of view.
From PATH_RESOLUTION(7) we read:
A filename (or pathname) is resolved as follows.
And afterwards we see that the first step is common for both hardlinks and symlinks (where system decides what is the starting point of path resolution: root directory
/, chrooted directory or current directory).
If the pathname starts with the '/' character, the starting lookup
directory is the root directory of the calling process. (A process
inherits its root directory from its parent. Usually this will be the
root directory of the file hierarchy. A process may get a different
root directory by use of the chroot(2) system call. A process may get
an entirely private mount namespace in case it—or one of its
ancestors—was started by an invocation of the clone(2) system call
that had the CLONE_NEWNS flag set.) This handles the '/' part of the
If the pathname does not start with the '/' character, the starting
lookup directory of the resolution process is the current working
directory of the process. (This is also inherited from the parent. It
can be changed by use of the chdir(2) system call.)
Pathnames starting with a '/' character are called absolute pathnames.
Pathnames not starting with a '/' are called relative pathnames.
As we see no difference to the starting point between hard- and symlinks. But, a difference does appear on the next step when walking the path begins:
Set the current lookup directory to the starting lookup directory.
Now, for each nonfinal component of the pathname, where a component is
a substring delimited by '/' characters, this component is looked up
in the current lookup directory.
If the process does not have search permission on the current lookup
directory, an EACCES error is returned ("Permission denied").
If the component is not found, an ENOENT error is returned ("No such
file or directory"). If the component is found, but is neither a
directory nor a symbolic link, an ENOTDIR error is returned ("Not a
If the component is found and is a directory, we set the current
lookup directory to that directory, and go to the next component.
As the description indicates there is no difference in path resolution for files and hardlinks - the process is the same. And what about symlinks? We read further:
If the component is found and is a symbolic link (symlink), we first
resolve this symbolic link (with the current lookup directory as
starting lookup directory). Upon error, that error is returned. If
the result is not a directory, an ENOTDIR error is returned. If the
resolution of the symlink is successful and returns a directory, we
set the current lookup directory to that directory, and go to the next
component. Note that the resolution process here can involve
recursion if the prefix ('dirname') component of a pathname contains a
filename that is a symbolic link that resolves to a directory (where
the prefix component of that directory may contain a symbolic link,
and so on). In order to protect the kernel against stack overflow,
and also to protect against denial of service, there are limits on the
maximum recursion depth, and on the maximum number of symbolic links
followed. An ELOOP error is returned when the maximum is exceeded
("Too many levels of symbolic links").
As it's indicated above, symlinks resolution requires additional disk access operations, so answering both questions:
If a hard link /hL is given, pointing to the inode of the above file,
in what order is the disk accessed?
If a soft link /sL is given, pointing to the above file, in what order
is the disk accessed?
we can conclude, that hardlinks access doesn't differ from ordinary file access, but symlinks resolution requires additional disk access operations, namely, symbolic link resolution.