-
Notifications
You must be signed in to change notification settings - Fork 0
/
files.html
762 lines (643 loc) · 31.3 KB
/
files.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
---
layout: default
title: Files
last-updated: April, 2024
---
<!--
<li> Wirzenius, L. (2004). Chapter 3: Overview of the Directory Tree. In <em>Linux System Administrator's Guide.</em> <a href="https://www.tldp.org/LDP/sag/html/fs-background.html">https://www.tldp.org/LDP/sag/html/fs-background.html</a></li>
-->
<div id="nav_bar_2" class="nav">
<ul>
<li><a href="#introduction"> Introduction </a></li>
<li><a href="#files"> Files </a></li>
<li><a href="#regular-files"> Regular Files</a></li>
<li><a href="#device-files"> Device Files </a></li>
<li><a href="#pseudo-files"> Pseudo Files </a></li>
<li><a href="#basic-file-operations">Basic File Operations</a></li>
<li><a href="#fs-heir"> Filesystem Hierarchy </a></li>
<li><a href="#mounting"> Mounting a Filesystem</a></li>
<li><a href="#directories">Directories</a></li>
<li><a href="#original-unix"> The Original Unix Filesystem</a></li>
<li><a href="#engineer-man">Engineer Man</a></li>
<li><a href="#references"> References </a></li>
</ul>
</div>
<div id="introduction" class="content">
<h1>Files</h1>
<div class="quote-text">
"Theory and practice sometimes clash. <br>
And when that happens, theory loses.
Every single time."
</div>
<div class="quote-ref">
<a href="https://lwn.net/Articles/326505/">Linus Torvalds</a>
</div>
<p>
The protogenesis of Unix was a filesystem.<sup><a href=#references>[1]</a><a href="http://read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf">[2]</a></sup>
Designed and implemented by the researchers of Bell Laboratories,
this piece of software became an operating system
when a means of interacting with its contents was
introduced.
Being a Unix-like operating system, GNU/Linux
inherits Unix's file semantics.
</p>
</div>
<div id="files" class="content">
<h2>Files</h2>
<p>
In Unix, a file is a sequence of bytes.<sup><a href=#references>[1]</a></sup>
This definition is sufficiently abstract to allow, for instance, a keyboard
to appear as a file.
Unix-like operating systems facilitate interaction with
files through four essential system calls:
</p>
<ol>
<li><em><a href="https://www.man7.org/linux/man-pages/man2/open.2.html">open()</a></em></li>
<li><em><a href="https://www.man7.org/linux/man-pages/man2/close.2.html">close()</a></em></li>
<li><em><a href="https://man7.org/linux/man-pages/man2/read.2.html">read()</a></em></li>
<li><em><a href="https://man7.org/linux/man-pages/man2/write.2.html">write()</a></em></li>
</ol>
<p>
In particular, the <em>read()</em> system call fills a given
buffer with the contents of a file;
order is preserved across sequential calls to <em>read().</em>
When a program requests a read, the kernel suspends its execution,
loads the appropriate data, then resumes execution of the program.
</p>
<h3>File Attributes</h3>
<p>
A substantial amount of information about each file is stored
on the system.
Such information is called
<em><a href="https://en.wikipedia.org/wiki/Metadata">metadata</a>,</em>
though within the context of Unix files,
it is usually referred to as <em>file attributes.</em>
</p>
<p>
File attributes consist of:
</p>
<div class="aside-right">
<h4>Aside:</h4>
<p>
Oddly, this information does not include the file's name.
More on that later.
</p>
</div>
<ul>
<li>File Type</li>
<li>Read/Write/Execute Permissions</li>
<li>Owner</li>
<li>Group</li>
<li>Size</li>
<li>Timestamps</li>
</ul>
<p>
This data is stored alongside the file, typically on-disk,
and its quantity can be explained by Unix's time-sharing heritage.
It is used today to compartmentalize the machine.
</p>
</div>
<div class="content" id="regular-files">
<h2>Regular Files</h2>
<p>
A regular file is stored on a disk or other persistent storage
device.
Most files are regular files.
</p>
<p>
Here we have a typical <a href="https://man7.org/linux/man-pages/man1/ls.1.html"><code>ls</code></a> listing:
</p>
<a href="assets/img/ls-long.pdf" target="_blank"><img src="assets/img/ls-long.png" style="width: 100%" title="Click for PDF" ></a>
<div class="aside-right" style="margin-top:25px;">
<h4>Aside:</h4>
<p>
Access restrictions are enforced by the kernel.
</p>
</div>
<p>
The first character, a hyphen (<code>-</code>), tells us that
<code>bash</code> (located in <br><code>/usr/bin</code>) is a regular file.
The next nine characters are its
<a href="http://linfo.org/permissions.html">permission bits</a>;
the <code>r</code> and <code>x</code> present in each trio indicate
that this file is readable and executable (respectively) by any user on
the system.
The <code>w</code> present only in the owner trio indicates that the
file may be written to only by its owner, who in this case
is <code>root</code>.
</p>
<p>
Two other tools for peeking
into a file are <code><a href="https://www.man7.org/linux/man-pages/man1/file.1.html">file</a></code>, which attempts to categorize the file, and
<code><a href="https://man7.org/linux/man-pages/man1/stat.1.html">stat</a></code>, which prints the file's complete metadata:
</p>
<div class="code">
$ file /usr/bin/bash<br>
/bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), <br>
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, <br>
BuildID[sha1]=a43fec47192ff49c2d3fed671f2be8df7e83784a, for <br>
GNU/Linux 3.2.0, stripped<br><br>
$ stat /usr/bin/bash<br>
File: /usr/bin/bash<br>
Size: 1183448 Blocks: 2312 IO Block: 4096 regular file<br>
Device: 802h/2050d Inode: 1835042 Links: 1<br>
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)<br>
Access: 2020-07-14 13:33:43.628528710 -0500<br>
Modify: 2020-02-25 06:03:22.000000000 -0600<br>
Change: 2020-07-09 11:20:12.676956656 -0500<br>
Birth: -<br>
</div>
<p>
To simply view the contents of a file, we can use the
<a href="https://www.greenwoodsoftware.com/less/"><code>less</code></a>
paging utility, which interprets the file as text.
</p>
</div>
<div id="device-files" class="content">
<h2>Device Files</h2>
<p>
The Unix directory tree is used as a general-purpose
meeting place:
In addition to regular files, it also contains references to
hardware, offers information about the running system,
and allows interprocess communication.
This mechanism is general, extensible, and allows both users
and programmers access to the running machine.
</p>
<p>
A <em>device file</em> is a file that represents a device
connected to the system.
Device files reside in <code>/dev</code>.<sup><a href="https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s06.html">[3]</a></sup>
For example, when a USB-stick is inserted,
a new file appears in <code>/dev</code>, and the device may be
read from or written to (directly) by passing
that file to tools like <code>cat</code> or <code>dd</code>.
</p>
<p>
It's interesting to note that the essential capabilities
of the USB-stick are preserved through the
file interface: It can be read from and written to.
If we were to add the capacity to
<a href="https://man7.org/linux/man-pages/man2/lseek.2.html">seek</a>
(i.e., change location) within the file, then we would be able to use the
device in its entirety.
</p>
<h3> Block and Character Device Files </h3>
<p>
Unix kernels support two kinds of device files:
Block and Character.
A character device file may only be read from or written to
a single byte (ASCII character) at a time.
A keyboard is one kind of device represented by a
character device file.
</p>
<p>
Hard disks, SSD's and removable mass media are represented by
block device files:
These devices support reading and writing only
in blocks of bytes at a time, and the kernel must
buffer arbitrary interactions with it.
Additionally, block device files support seeking, whereas
character devices do not.
</p>
<h3>See Also:</h3>
<ul>
<li><a href="https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks#Introduction_to_block_devices">Introduction to Block Devices</a> (From "Preparing the Disks") - Gentoo Wiki</li>
<li><a href="https://wiki.archlinux.org/index.php/Device_file">Device File - ArchWiki</a></li>
</ul>
</div>
<div class="content" id="pseudo-files">
<h2>Pseudo Files</h2>
<p>
The Linux kernel augments the traditional Unix directory tree with
<em>pseudo</em> (or "synthetic") files.
These files do not exist on disk, and do not exist on
any persistent storage.
Instead, their contents are generated dynamically
by the kernel as processes interact with them.
</p>
<p>
For example, <code>/proc/meminfo</code> contains a
description of the system's current memory usage:
</p>
<div class="code">
$ cat /proc/meminfo<br>
MemTotal: 3887988 kB<br>
MemFree: 1619568 kB<br>
MemAvailable: 2450268 kB<br>
Buffers: 120152 kB<br>
Cached: 984208 kB<br>
SwapCached: 0 kB<br>
Active: 324532 kB<br>
Inactive: 1528196 kB<br>
Active(anon): 9476 kB<br>
Inactive(anon): 1061224 kB<br>
[...]
</div>
<p>
<code>/proc</code> contains one directory for each
process (running program) on the system; therein, each directory
contains substantial information about its respective process.
<code>/sys</code> contains information useful to only the
lowest-level system daemons.<sup><a href="http://linuxfromscratch.org/lfs/view/stable/chapter09/udev.html">[4]</a></sup>
</p>
<p>
<strong>Other File Types:</strong>
<ul style="width: 70%; margin-left: 5%;">
<li>
<strong>FIFO:</strong>
Also called a "pipe", "FIFO" stands for <em>First in, first out</em>.
This is file type is used to connect one running program to another.
</li>
<li>
<strong>Socket:</strong> A FIFO, but across networks.
</li>
</ul>
</p>
<h3>See Also:</h3>
<ul>
<li> <a href="https://www.kernel.org/doc/html/latest/filesystems/proc.html">The <code>/proc</code> Filesystem – The Linux Kernel documentation </a></li>
<li> <a href="https://mirrors.edge.kernel.org/pub/linux/kernel/people/mochel/doc/papers/ols-2005/mochel.pdf">The <code>sysfs</code> Filesystem</a> by Patrick Mochel</li>
</ul>
</div>
<div class="content" id="basic-file-operations">
<h2 style="margin-bottom: 0;">Basic File Operations</h2>
<h4>and Introduction to Directories</h4>
<p>
Basic command-line utilities to manipulate files are:
</p>
<ul>
<li><code><a href="https://man7.org/linux/man-pages/man1/touch.1.html">touch</a></code> - Change file timestamps.
Can be used to create new, empty files.</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/cp.1.html">cp</a></code> - Copy files and directories</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/rm.1.html">rm</a></code> - Remove files or directories</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/mv.1.html">mv</a></code> - Move (or rename) files</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/chown.1.html">chown</a></code> - Change file owner and group</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/chmod.1.html">chmod</a></code> - Change access permissions</li>
</ul>
<p>
Utilities to display and inspect file contents:
</p>
<ul>
<li><code><a href="https://man7.org/linux/man-pages/man1/cat.1.html">cat</a></code> - Concatenate files and print on the standard output</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/head.1.html">head</a></code> - Output the first part of a file</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/wc.1.html">wc</a></code> - Print line count, word count, and byte count</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/sort.1.html">sort</a></code> - Sort lines of text</li>
</ul>
<p>
Utilities to manipulate directories:
</p>
<ul>
<li><code><a href="https://man7.org/linux/man-pages/man1/mkdir.1.html">mkdir</a></code> - Make directories</li>
<li><code><a href="https://man7.org/linux/man-pages/man1/rmdir.1.html">rmdir</a></code> - Remove empty directories</li>
</ul>
<h3>Introduction to Directories</h3>
<div class='aside-right'>
<h4>Aside:</h4>
<p>
<code><a href="https://man7.org/linux/man-pages/man1/find.1.html">find</a></code> recursively descends through a directory
tree in search of files.
</p>
</div>
<p>
Directories are a special kind of file, and early Unix
kernels allowed them to be manipulated relatively unabated.<sup><a href="http://read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf">[2]</a></sup>
However, the directory structure is intended to be a
hierarchy, and some software (like <code>find</code>)
depends upon this structure.
Leaving directory contents exposed to users introduced the
possibility that a loop could form, or that a
directory subtree could be broken off without being properly
deallocated.<sup><a href="https://dsf.berkeley.edu/cs262/UNIX-annotated.pdf">[5]</a></sup>
So, directories are now hidden behind a separate system
call interface.
</p>
<p>
Directories start life with two entries:
<code>.</code> ("dot"),
and <code>..</code> ("dot dot").
These entries cannot be removed, nor changed.
The first, <code>.</code>, is a reference to the containing directory
itself,
and is used as a handle to the current working directory.
<code>..</code> is a reference to the directory's
parent directory.
</p>
<p>
Since each directory has exactly one parent,
the directory structure is guaranteed to be a tree.
</p>
<h3>See Also:</h3>
<ul>
<li><a href="https://www.gnu.org/software/coreutils/manual/html_node/index.html">GNU coreutils</a> - Table of Contents</li>
</ul>
</div>
<div id="fs-heir" class="content">
<h2>Filesystem Hierarchy</h2>
<div class="img-center">
<a title="Dhanusha Dhananjaya, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0>, via Wikimedia Commons" href="https://commons.wikimedia.org/wiki/File:Linux_file_system_foto_no_exif_(1).jpg"><img width="512" alt="Linux file system foto no exif (1)" src="https://upload.wikimedia.org/wikipedia/commons/4/4b/Linux_file_system_foto_no_exif_%281%29.jpg"></a>
</div>
<p>
Within a Unix directory tree, some common themes will be found.
For instance, <code>bin</code> directories are found in several places, such as
<code>/bin</code>, <code>/sbin</code>, along with <code>/usr/bin</code>
and often <code>/home/<i>user</i>/.local/bin</code> as well.
These contain binary executable files— programs— such as
<code>bash</code> and <code>ls</code>.
Other standard directories include <code>/root</code>, the root user's home
directory, and <code>/proc</code> and <code>/dev</code>, as
mentioned above.
Some of these have been standard since Unix's inception,
while others have become standard in more recent years.
</p>
<div class="aside-right" style="font-size: 15px;">
<h4>Aside:</h4>
<p>
The <a href="https://refspecs.linuxfoundation.org/fhs.shtml">Filesystem Hierarchy Standard</a> formally
describes the GNU/Linux directory tree. It is maintained
by the Linux Foundation.
</div>
<p>
Let's start at the top.
Each Unix-like operating system has a single root directory,
<code>/</code>, which is the root of the directory tree.
Every file on the system may be addressed in
absolute terms by giving its location relative to this
directory.
</p>
<p>
<code>/home</code> contains users' home directories.
As user <em>josh</em>, my home directory is <code>/home/josh</code>.
This path is commonly abbreviated to <code>~</code>.
By default, it contains the usual "Music", "Movies", "Pictures" and
"Downloads".
Per-user configuration files are stored here— as either
hidden files or in the directory <code>~/.config</code>.
</p>
<p>
The <code>/usr</code> directory is dedicated to
user-space (as opposed to kernel-space) files.<sup><a href="https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html">[6]</a></sup>
It contains programs, libraries, manual pages, C header
files, and other things.
These files are shared by all system users, and are read-only.
</p>
<div class="aside-left">
<h4>Pro Tip:</h4>
<p>
As a rule, modify <code>/etc</code>, and let your
distribution handle <code>/usr</code>.<sup><a href="https://nostarch.com/howlinuxworks3" title="Ward">[7]</a></sup>
</p>
</div>
<p>
System configuration is traditionally maintained as a collection of
plain-text, human-readable regular files.
System-specific configuration is kept in <code>/etc</code>,
while distributions' default configurations are typically
stored in <code>/usr</code> (alongside their respective packages).
</p>
<p>
<code>/tmp</code>, <code>/run</code>, and <code>/var</code> each hold
transient files of running programs.
<code>/boot</code> holds everything required for the boot sequence,
including my very own Linux kernel:
</p>
<div class="code">
$ file /boot/Image<br>
Image:   Linux kernel ARM64 boot executable Image, little-endian, 4k pages
</div>
<p>
This file is copied (loaded) into memory early in the boot process,
after which it is no longer needed.
</p>
<p>
Software libraries are kind of boring, but essential to modern systems.
The basic idea is to factor out repeated code (for instance,
C's <code>printf</code> function) not just from the source code, but
from <em>executable</em> files as well.
This means that, when a bug or security vulnerability is found in
<code>printf</code>, any program that uses the function will not
have to be recompiled; rather, the appropriate library can be adjusted,
and all dependant programs can continue operation in blissful ignorance
of the change.
Such executable files are said to be <em>dynamically linked,</em>
and cannot be expected to run properly without their dependencies.
<code>/lib</code> holds libraries.
</p>
</div>
<div class="content" id="mounting">
<h2>Mounting a Filesystem</h2>
<p>
As mentioned, Unix-like operating systems maintain a single
directory tree for the entire system.
When a new device is introduced to the machine,
the directory tree its filesystem contains must be placed in the
system's existing directory tree before its contents can
be accessed.
This operation is known as <em>mounting.</em>
</p>
<p>
Let's take a look at this, for it is new.
Suppose we have a USB stick with some music on it.
When we plug it into the machine, a file representing
the device appears in <code>/dev</code>, but
its contents are not yet available:
</p>
<img style="width:80%" src="assets/img/mounting1.png">
<p>
Assuming the device popped up as "<code>/dev/usb</code>",
we could mount it with,
</p>
<div class="code">$ sudo mount /dev/usb /mnt</div>
<p>
Resulting in:
</p>
<img style="width:80%" src="assets/img/mounting2.png">
<p>
The files are now accessible through the directory tree.
</p>
<p>
In practice, a USB-device is
<a href="https://wiki.archlinux.org/title/Device_file">much more likely</a> to be named
<code>/dev/sdb</code> or <code>/dev/sdc</code>, with partitions,
<code>/dev/sdc1</code>, <code>/dev/sdc2</code>, <code>/dev/sdc3</code>, <code>...</code> .
Hence, a more realistic call to <code>mount</code> would be,
</p>
<div class="code">
$ sudo mount /dev/sdc1 /mnt
</div>
<p>
When a filesystem is mounted to a directory that is not empty,
the original directory's contents become hidden by those
of the new filesystem,
and are inaccessible until the filesystem is unmounted.
Therefore, we typically locate an empty directory in the existing
directory tree, and use it as the to-be mounted filesystem's root
directory.
</p>
<h3>See Also:</h3>
<ul>
<li><a href="https://youtu.be/2Z6ouBYfZr8">Linux Essentials - Formatting & Mounting Storage Volumes</a> LearnLinuxTV (Youtube Video)</a></li>
<li><a href="https://wiki.archlinux.org/title/File_systems#Mount_a_file_system">Mount a file system</a> - ArchWiki (from <em>File Systems</em>)</li>
<li><a href="https://docs.fedoraproject.org/en-US/fedora/f28/install-guide/appendixes/Disk_Partitions/">An Introduction to Disk Partitions</a> :: Fedora Docs</a></li>
<li><a href=""><code>lsblk(8)</code></a> - List block devices</li>
</ul>
</div>
<div class="content" id="directories">
<h2 style="margin-bottom: 0;">Directories</h2>
<h4>and Filenames</h4>
<p>
An <em>inode</em> is a collection of data describing a file.
It contains all metadata of the file, as well as
a sequence of references to the data
constituting the file.
Within a filesystem, inodes are located in an array, so that
an index into this array uniquely identifies an inode, and
thereby identifies a specific file.
These indices are referred to as <em>inode numbers.</em>
</p>
<p>
A <em>directory</em> is a file which associates filenames with
inode numbers.
Both literally and conceptually, a directory is a file containing
a two-column table, inode number and filename:
</p>
<div class="aside-right">
<h4>Remember:</h4>
<p>
Every path on the directory tree terminates in a
inode reference.
</p>
</div>
<div class="code">
$ ls -ia ~/Public/Learning-Linux <br>
645278 ./<br>
384844 ../<br>
775487 assets/<br>
645403 _config.yml<br>
775449 _data/<br>
642188 documentation.html<br>
641473 files.html<br>
775463 how-open-source-works.html<br>
[...]
</div>
<p>
Here we have the file's inode numbers on the left, and its
associated filename on the right.
Each inode/filename number pair is called a <em>hard link.</em>
A file may have more than one hard link, but when it has zero,
it is no longer accessible through the directory tree, and
the kernel prepares to delete it.<sup><a href="#references">[8]</a></sup>
</p>
<h3>Filenames</h3>
<p>
Unix-like operating systems allow files to be named very flexibly:
Filenames may include any character except <code>/</code>,
the path separator, and <code>\NULL</code>, the
end-of-string delimiter.
More, it is not required that filenames terminate in any special
postfix; in particular, a file is executable exactly when its
permissions say so.
</p>
<div class="aside-right">
<h4>Aside:</h4>
<p>
Hidden files are strictly a user-space convention, and have no
meaning, <i>per se,</i> with respect to the system.
</p>
</div>
<p>
As a rule, filenames are not interpreted by the kernel,
and exist for user interpretation alone.
Filenames beginning with <code>.</code>
are considered hidden (including <code>.</code> and <code>..</code>).
They can be listed by <code>ls</code> with the <code>-a</code>
("all") switch:
</p>
<div class="code">
$ ls -a
</div>
<h3> See Also: </h3>
<ul>
<li><a href="http://linfo.org/hard_link.html">What is a hard link?</a> -- definition by The Linux Information Project (LINFO)</li>
<li><a href="http://www.linfo.org/inode.html">Inode Definition</a> by The Linux Information Project (LINFO)</li>
<li> <code><a href="https://man7.org/linux/man-pages/man7/inode.7.html"> inode(7) </a></code></li>
<li><a href="https://en.wikipedia.org/wiki/Symbolic_link#Overview"> Symbolic Link (Overview)</a> - Wikipedia</li>
</ul>
</div>
<div class="content" id="original-unix">
<h2>The Original Unix Filesystem</h2>
<p>
The inode was implemented literally in the Research Unix filesystem,
and formed the basis of its architecture:
</p>
<a href="./assets/img/inode.pdf"><img src="./assets/img/inode.png"></a>
<p>
In the design, every file is represented by a single inode,
which contains the file's metadata, and contains pointers to
data blocks, where the contents of the file are kept.<sup><a href="#references">[9]</a></sup>
These nodes are arranged in an array, and can be identified
by an index into it.
Data blocks are of fixed size, and either free or
wholly consumed by a file.<sup><a href="#references">[9]</a></sup>
</p>
<p>
This design allows a file to grow or shrink without rearranging
other files.<sup><a href="#references">[9]</a></sup>
In addition, the inclusion of single-, double- and triple-
indirection blocks allow the inode to remain of fixed,
reasonable size, while supporting large
files.<sup><a href="#references">[9]</a></sup>
Finally, by keeping the inode array in memory,
the design fosters the speedy retrieval of data in small
files.<sup><a href="#references">[9]</a></sup>
</p>
<p>
It was the most advanced filesystem of its time,
and as Unix grew in popularity,
the semantics of file operations in Unix-like operating systems
became dependant upon them.
The design was demonstrated in the
<a href="https://en.wikipedia.org/wiki/Minix">MINIX</a> filesystem,
which in turn served as Linux's first filesystem.
The <em>extended</em> filesystem, <code>ext</code>, extended
that filesystem's capabilities.
With <code>ext</code>'s inclusion in kernel 0.96c, Linux began to use
its new <a href="https://www.kernel.org/doc/html/latest/filesystems/vfs.html">Virtual File System</a>,
a kernel subsystem that provides userspace with a
uniform filesystem interface.
</p>
<p>
While each filesystem implements its own functionality,
most functionality is common;
the Virtual File System maps system calls
to filesystem-specific functions.<sup><a href="https://www.kernel.org/doc/html/latest/filesystems/vfs.html">[10]</a></sup>
In addition, it imposes inodes on filesystems that do not
natively employ them, thereby preserving traditional Unix file
semantics across all supported filesystems.<sup><a href="https://www.kernel.org/doc/html/latest/filesystems/vfs.html">[10]</a></sup>
</p>
<h3>See Also:</h3>
<ul>
<li><a href="https://warsus.github.io/lions-/"> A Commentary on the UNIX Operating System</a> by John Lions (Webversion by warsus)</li>
<li><a href="https://archive.org/details/designofunixoper00bach/mode/2up">The Design of the Unix Operating System</a> by Maurice Bach</li>
</ul>
</div>
<div id="engineer-man" class="content">
<h2 style="margin-bottom: 2pt;">Engineer Man</h2>
<h4 style="margin-bottom: 18pt;">The Linux File System ...for humans</h4>
<iframe class="video" src="https://www.youtube.com/embed/UFIoRLqhFpo" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</div>
<div id="references" class="content">
<h2> References </h2>
<ol>
<li> Kernighan, Brian. <i>Unix: A History and a Memoir.</i> Published 2020, by Brian W. Kernighan via Kindle Direct Publishing. </li>
<li>Ritchie, D. M. (1984). <a href="http://read.seas.harvard.edu/~kohler/class/aosref/ritchie84evolution.pdf">The Evolution of the Unix Time-sharing System</a>. <em>AT&T Bell Laboratories Technical Journal,</em> 63(6), 2nd ser., 1577-1593.</li>
<li> LSB Workgroup, The Linux Foundation. (2015, March 9). 3.6 /dev: Device Files. Retrieved July 17, 2020, from <a href="https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s06.html">https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03.html</a> </li>
<li>Beekmans, G. (2021, March 1). 9.3. <em>Overview of Device and Module Handling.</em> 9.3. Overview of Device and Module Handling. <a href="https://linuxfromscratch.org/lfs/view/stable/chapter09/udev.html">https://linuxfromscratch.org/lfs/view/stable/chapter09/udev.html</a>.</li>
<li>Ritchie, D. M., & Thompson, K. (n.d.). The UNIX Time-Sharing System. UNIX-Annotated.pdf. <a href="https://dsf.berkeley.edu/cs262/UNIX-annotated.pdf">https://dsf.berkeley.edu/cs262/UNIX-annotated.pdf</a>.</li>
<li>Nguyen, B. (2004, April 30). <em>The Linux Filesystem Heirarchy, Section 1.17. /usr. </em>/usr. <a href="https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html">https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html</a>.</li>
<li>Ward, B. (2021). <em><a href="https://nostarch.com/howlinuxworks3">How Linux Works: What Every Superuser Should Know</a></em> (3rd ed.). No Starch Press.</li>
<li> Kerrisk, Michael. <em>The Linux Programming Interface</em>. San Francisco, CA, No Starch Press, 2010.</li>
<li>Bach, M. J. (1986). Chapter 4: Internal Representation of Files. In <em>The Design of the UNIX Operating System</em> (pp. 60-90). Englewood Cliffs, NG: Prentice-Hall. </li>
<li> Overview of the Linux Virtual File System - The Linux Kernel Documentation. (n.d.). Retrieved July 17, 2020, from <a href="https://www.kernel.org/doc/html/latest/filesystems/vfs.html">https://www.kernel.org/doc/html/latest/filesystems/vfs.html</a> </li>
</ol>
</div>