File Systems: Names, Blocks and Metadata
In an inode-based, block-backed file system, directories map names to records. Records hold metadata and information locating file bytes. Paths follow these mappings; hard links share a record. Removing a name differs from copying bytes or immediately reclaiming storage.
What a learner can do afterwards
- Resolve absolute and relative paths and follow directory entries through records to data blocks
- Explain hard links as names sharing one record and predict the result of removing one name
- Explain why unlinking avoids overwriting file contents without guaranteeing instant deletion or reclamation
1 · Read
An absolute path starts at a file-system root. A relative path starts at the process's current working directory. In our inode-based model, each directory maps a component name to a record. Intermediate components lead through directories. If the working directory is /home/ana, notes/draft.txt resolves to /home/ana/notes/draft.txt.
Paging tracks page residency in RAM frames. Here we use a block-backed, inode-based file-system model. Storage blocks are not RAM frames. A directory entry maps a name to a record; it does not contain the named file's contents. A file record holds metadata such as owner, type, permissions and size, plus information locating data blocks. Follow the name to the record, then its block information to find the stored bytes.
For a regular file, ls -l may show -rw-r--r--. The leading dash marks a regular file. The next nine positions are owner, group and other fields, each with read, write and execute slots. A dash means absent. chmod 600 myfile.txt sets rw-------: owner read/write, group and other none. These mode bits do not describe every possible access or action.
Hard-link names for a regular file refer to the same record on the same file system. Neither name is a special original. Both reach the same contents and metadata. Adding a hard link adds a directory entry, not an independent copied file. This discussion does not concern symbolic links or links to directories.
Unlinking removes a directory entry and reduces the link count without overwriting every content block. It can be quick, but storage reclamation may need more metadata work. An ordinary byte-by-byte copy reads source bytes and writes destination contents associated with a distinct file record. Some file systems let distinct copies share physical blocks until changes require separation.
Removing one hard-link name leaves other names for the same file usable. After the last name is removed, an open file handle can still keep the file usable. In this model, space becomes reclaimable when no hard links or open handles remain. Reclamation need not be instant. Unlinking is not secure erasure; old bytes may remain until storage is reused.
Directories map names to records; records locate data blocks. Hard links share a record. Unlinking removes a name without overwriting every content block.
Lesson, worked questions and flashcards about paths, records, permissions and hard links were written for this dataset.
Two readings and six flashcards about permissions, paths, file records and links were written for this dataset.
More to read
Separate user classes from permission slots
A regular-file listing can begin -rw-r--r--. The leading dash identifies a regular file. Split the next nine positions into rw-, r-- and r--. These fields belong to the owner, group and other users. Within each field, positions mean read, write and execute; a dash marks an absent permission.
For a file you own, chmod 600 myfile.txt requests owner read/write and no group or other mode permissions. Inspect the listing afterwards to check the result. Permission metadata is not text inserted into the file's contents.
These mode bits do not describe every possible action. Privileged access, other access rules and already-open handles can matter. Removing a name also depends on directory permissions. Changing metadata requires work and is not guaranteed to finish instantly.
Names and copied contents are different
Start an absolute path at a file-system root and a relative path at the current working directory. In an inode-based model, directory entries connect names to records. A regular file's record supplies metadata and information locating its data blocks.
A hard link adds another name for the same record on the same file system. Removing one name leaves another hard link usable. Even after the last name is removed, an open handle can keep the file usable.
A byte-by-byte copy instead reads source bytes and writes destination contents associated with a distinct record. Some file systems let independent copies share physical blocks until changes require separation. That is different from hard links sharing one record. Unlinking is not secure erasure of stored bytes.
2 · Watch
En anglaisTake it off screen
Where it sits
Learn first
Optional connections
This opens up
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.