File Retrieval Using Inodes:
In Linux, every file and directory is identified by an inode. When a user requests to access a file,
the kernel performs a series of steps to locate the file on the disk using its inode. If the file is
identified by its absolute path, the system follows a structured process to retrieve the file
efficiently. This lecture explores how the inode is used in the file retrieval process when an
absolute path is given.
1. What is an Absolute Path?
An absolute path in Linux is a complete path to a file or directory, starting from the root
directory (/). It provides the full location of the file in the filesystem hierarchy.
Example of an absolute path:
/etc/[Link]
In Linux, files are identified by inodes, which store metadata about the file. The file retrieval
process involves:
1. Parsing the Absolute Path to navigate the directories.
2. Accessing Directory Inodes to locate the file.
3. Using the Inode to access the file's metadata and data blocks.
Let’s walk through how this works for /etc/[Link].
3. Step-by-Step File Retrieval Process for /etc/[Link]
Step 1: Start with the Root Directory /
The kernel begins by reading the root directory (/).
The root directory itself has an inode, which contains metadata about the directory, including
pointers to its data blocks (where the actual list of directory entries is stored).
At this stage, the kernel reads the inode of the root directory (/).
The inode for / contains a list of directory entries, one of which is etc, pointing to the inode of
the /etc directory.
Step 2: Traverse the /etc Directory
The kernel moves to the /etc directory by accessing its inode, which is stored in the
directory entry for etc in the root directory.
The /etc directory contains several entries, and the kernel searches for the [Link] entry.
The directory entry for [Link] in /etc contains the inode number for [Link].
Step 3: Access the Inode of [Link]
After finding the directory entry for [Link] in /etc, the kernel retrieves the inode number
associated with the file.
The kernel then accesses the inode of [Link], which contains important metadata, such as:
o Permissions: Who can read, write, or execute the file.
o File Size: The size of [Link].
o Timestamps: Information about when the file was last modified, accessed, or created.
o Pointers to Data Blocks: Addresses where the actual content of the file is stored on the
disk.
Step 4: Retrieve the File Data
The kernel uses the pointers in the inode of [Link] to find the data blocks where the content of
the file is stored.
It accesses these data blocks on the disk to retrieve the file’s content.
Finally, the content of [Link] is returned to the user.
6. Inode Example for /etc/[Link]
Let’s visualize how this works with a simplified structure for /etc/[Link]:
1. Root Directory (/):
o The root directory has an inode (let’s say inode number 2) that points to data
blocks containing the directory entries, including etc.
o /etc is a directory entry with an inode number (say inode number 101).
2. /etc Directory:
o The /etc directory has an inode (inode number 101).
o Inside /etc, there is an entry for [Link], which points to inode number 202.
3. [Link] File:
o The inode number 202 corresponds to [Link].
o The inode 202 contains the file's metadata (permissions, timestamps, etc.) and
pointers to the actual data blocks where [Link]'s content is stored.
1. Attempting to Access /etc/[Link]
When you try to access /etc/[Link], the system first starts at the root directory /.
The kernel checks the directory entries in the root directory's inode (Inode 2 in our
example).
It searches for the etc directory within the directory entries. If etc does not exist, the
kernel will not find an inode for etc.
2. Directory Not Found
Since the etc directory does not exist in the root directory, there will be no directory
entry for it, and thus no inode pointing to the /etc directory.
The file path /etc/[Link] cannot be resolved because the system cannot locate etc to
even begin searching for [Link] inside it.
3. Error Occurs
The system will report an error such as "No such file or directory" because it couldn't
find the etc directory to proceed further.
If a user does not have access to the /etc directory (or lacks the necessary permissions), the
behavior of the system when trying to access /etc/[Link] will be different. Here's what happens:
1. Attempting to Access /etc/[Link]
The user tries to access /etc/[Link], which is a file inside the /etc directory.
The kernel will first check the /etc directory inode to confirm the existence of [Link]. If
the directory and file exist, it will then check if the user has the required permissions to
access it.
2. Permission Check for /etc Directory
The system will check the permissions of the /etc directory.
o Directory Permissions: A user needs read (r) and execute (x) permissions on a
directory to list its contents and access files inside it. Specifically, execute ( x)
permission is required to access files within a directory.
o If the user does not have read (r) or execute (x) permissions on /etc, the kernel
will not allow the user to open the directory or access files within it, including
/etc/[Link].
3. Denied Access to /etc
If the user does not have the necessary permissions (for example, if the permissions on
/etc are restricted to the root user), the system will respond with a permission denied
error:
bash
Copy
bash: /etc/[Link]: Permission denied
The error could be:
o "Permission denied" when trying to list contents or access the file.
o If the user is attempting to open the file directly with a command like cat, ls, or
nano, the error would indicate that the user does not have sufficient permissions
to read or execute within /etc.
4. Permission Check for /etc/[Link]
If the user somehow bypasses or directly references the file (/etc/[Link]), the system
will check file permissions on [Link].
o Read Permission: Even if the directory is accessible, the user must have read (r)
permission on the file [Link] itself to view or open it.
o If the user does not have read permission on [Link], the system will deny access
to the file and show an error such as:
bash
Copy
cat: /etc/[Link]: Permission denied
Hard Link in Linux
A hard link is essentially a pointer to the same inode of a file, meaning that it points to the exact
same data on the disk as the original file. Both the original file and the hard link share the same
inode number, and thus, any changes made to one are reflected in the other, because they refer to
the same underlying data blocks. One important thing to note is that hard links cannot be created
for directories (except for . and ..), and they must exist within the same filesystem.
Example:
Suppose you have a file called [Link] in your directory. You can create a hard link to
[Link] with the following command:
bash
Copy
ln [Link] file_link.txt
Now, both [Link] and file_link.txt refer to the same inode and data on the disk. If you
modify the contents of file_link.txt, the changes will be reflected in [Link] as well, and
vice versa. You can verify that both files point to the same inode using the ls -i command:
bash
Copy
ls -i [Link] file_link.txt
If both files have the same inode number, it confirms they are hard links to the same data. If you
delete [Link], file_link.txt will still contain the file's data, as they are both referencing
the same inode.
Soft Link (Symbolic Link) in Linux
A soft link, or symbolic link, is a special type of file that acts as a shortcut or reference to
another file or directory. Unlike a hard link, which directly references the inode of a file, a soft
link contains a path to the original file. This means that the soft link points to the filename and
not the data itself. Soft links can span across different filesystems and can link to directories as
well. If the original file is deleted or moved, the soft link will become broken (pointing to a non-
existent file).
Example:
Suppose you have a file [Link] in your directory. To create a soft link to [Link], you can
use the ln -s command like this:
bash
Copy
ln -s [Link] file_link.txt
Now, soft_link.txt is a symbolic link to [Link]. If you list the details of soft_link.txt
using ls -l, you'll see that it shows the path of the target file:
bash
Copy
ls -l file_link.txt
The output will look something like this:
sql
Copy
lrwxrwxrwx 1 user user 8 Feb 25 12:00 file_link.txt -> [Link]
Here, l at the beginning of the output indicates it's a symbolic link, and -> [Link] shows the
path to the original file.
If you modify soft_link.txt, the changes will affect [Link]. However, if [Link] is
deleted or moved, soft_link.txt will no longer work, and attempting to access it will result in
an error because the link points to a non-existent file.
In contrast to hard links, soft links can link to files across different filesystems and directories,
making them more flexible but also more fragile if the target file is removed or relocated.