|
Operation systems of the Unix family feature a file
system order that is
- thoroughly hierarchical (one 'directory
tree'),
- specific to the function of a file and not
to its program context (no 'program directories').
Hierarchy here means that the directory tree is indeed
one tree. Directories follow a designed order starting from the root directory
('/') instead of having so-called 'drives'.
Within MS Windows, you may put your files (almost) anywhere: on 'C', 'D',
'E' etc. Hierarchical structures are managed by the programs themselves ('program
directories') and not by the operating system.
Unix (and therefore Linux) on the other hand sorts directories ascending from
the root directory '/' according to their importance for the boot process.
And here it is the operating system that determines into which directories
programs have to put their files into. Directories are not program- but function-specific.
If you install a program in MS Windows, it usually stores
most of its files in its own directory structure. A help file for instance
may be in 'program name\' or in 'program_name\help'
or in 'program name\hoopy\frog\turnip'.
In Linux, programs put their documentation into '/usr/share/doc/program_name',
man pages into '/usr/share/man/man[1-9]', info pages into '/usr/share/info'.That
is they are merged with the system hierarchy.
 section index  top
One reason for this arrangement is that a centralized
file system hierarchy is much easier to administer. For instance changes
on one machine can be easily transferred to the clients on the network.
A consequence of this structure is the concept of partition mounts which usually
confuses new users. All GNU/Linux partitions on your hard drive are mounted
to ('hooked into') mount directories (aka 'mount points'). And you access
them via these directories ('/' or '/usr' or '/mnt/cdrom' etc). This assures
a seamless integration into the system, regardless if the mount is a local
partition or one on the network server. And the mount names stay the same,
if there are partitions or external media mounted to them or not. In contrast
to Windows, where an additional local 'drive letter' changes all the 'drive
letters' behind it and networked partitions are handled as extra 'drives'.
Another reason is that Linux caches a lot of disk accesses using system
memory while it is running to accelerate these accesses.
It is therefore vitally important that these buffers are 'flushed' (i.e.
get their content written to disk), before the system closes down.
Else files are left in an 'undetermined state'. And that's a very bad thing
for files to be left in.
Flushing is achieved by 'unmounting' the partitions during proper system shutdown.
Don't switch your system off while it is running!
You may get away with it quite often, since the Linux file system is very
robust, but you may also wreak havoc upon important files. Just hit <CTRL
ALT DEL> or use the proper commands (e.g. init 6) / buttons.
This will shut down the system in a decent way and reboot it. And thus guarantee
the integrity of your files.
section index top
So far, I've told you how it should be. Now
about how it is in the real world ;-).
As you will see on the following pages, the implementation
of this concept on Linux isn't perfect. Some people would even say it's far
from perfect.
Linux has always attracted individualists. And these people tend to have their
own opinion about a great many things, like for instance into which directories
certain files should be put into. With the arrival of different distributions,
these different opinions became manifest. Some distributions put mount directories
for external media into the 'root' directory, others - like Mandrake Linux
- into '/mnt'. Red Hat based distributions feature the '/etc/sysconfig' sub-hierarchy
for configuration files concerning input and network devices. Other distributions
do not have this directory at all and put the appropriate files elsewhere
or even use completely different mechanisms to do the same thing. Some distributions
put KDE into '/opt/', others - like Mandrake Linux - into '/usr'
But even within a given file system hierarchy, there
are inconsistencies. The graphical subsystem, XFree86, has its own directory
hierarchy, for example. The hierarchy has not so much been designed as 'grown'.
So there are weeds.
This isn't much of a problem as long as you compile
programs yourself: you can then adapt their configure scripts or Makefiles
to your system's configuration. But it's different if you install pre-compiled
packages like RPMs. Often these are not adaptable from one file system hierarchy
to another. What's worse: some RPMs might even create their own hierarchy.
If you, say, install a KDE RPM from the SuSE Linux distribution on your ML
system, the binary will be put into '/opt/kde2/bin'. And thus it won't work,
because ML expects it to be in '/usr/bin'.
There are of course ways to circumvent this problem
(discussed in the article on RPM), but
the current situation clearly is unsatisfying. Therefore all the leading
GNU/Linux distributors have joined the Linux Standard Base project, which
is currently trying to create a common standard for GNU/Linux distributions.
As you might imagine, this isn't easy, because changing the file system hierarchy
means a lot of work for distributors. And so every distributor tries to push
a standard which will allow him to keep as much of his own hierarchy as possible
...
The LSB will also encompass the proposals made by the
File system Hierarchy
Standard project (FHS, former FSSTND). Starting with 7.2, Mandrake Linux
has taken some pains to reorganize its file system hierarchy for greater
FHS and LSB compliance. These changes will be discussed on the next pages,
too.
section index top
 The root Directory
|
