I had a recent email question that asked "How do you use the mount command correctly, in plain English, and what does it do?"
Whenever someone says "in plain English", you know that they have been
frustrated by "man" pages. Actually, the beginning of the man page for
"mount" isn't too bad. Here it is from my Mac:
The mount command calls the mount(2) system call to prepare and graft a
special device or the remote node (rhost:path) on to the file system tree
at the point node. If either special or node are not provided, the
appropriate information is taken from the fstab(5) file.
That's pretty straight forward and concise, but it does assume you
understand what a file system is and what a special device or remote node
might be. The man page for the system call (man 2 mount) is a
The mount() function grafts a filesystem object onto the system file tree
at the point dir. The argument data describes the filesystem object to
be mounted. The argument type tells the kernel how to interpret data
(See type below). The contents of the filesystem become available
through the new mount point dir. Any files in dir at the time of a suc-
cessful mount are swept under the carpet so to speak, and are unavailable
until the filesystem is unmounted.
But does that really explain it to the uninitiated? Probably not,
but as is so often the case, where do we start? How far back do
we need to unwind abstractions before it becomes clear what is going on?
You may be furrowing your eyebrows right now. "What's so difficult",
you wonder. Well.. let me take you back a few years.
In the beginning, we had floppy disks. Floppy disks stored files, and
that was that. There were no folders, no directories, just files.
You had commands to list the files ("dir" on DOS, for example), and
commands to execute them if they were programs. You could copy,
delete, and so on. Hierarchies of files were actually used long before DOS,
so I'm just using that as an example.
Pretty simple. There were limits: you could only have so many
files on a disk no matter how small they were, but that didn't bother
most folks. You had your disks, and your files were right there
in plain sight.
Then came directories, and panic set in. Really.
I was already doing computer support when hierarchical file
systems started appearing in PC's. People didn't "get" it. Oh, some
did, but for others the leap to this was almost too much. I
can well remember being puzzled by it myself at first - I
just couldn't "see" it, couldn't get a mental image of what this
meant. People would describe this in terms of filing cabinets:
you could throw your papers in haphazardly or you could organize them
into folders. That analogy helped some, but others were still
blank and helpless.
I dredged all that up because it shows that the mental
image we have of how our computers work can vary from person
to person. When I click on a folder to open it, I "see" that
from the perspective of a programmer: I'm opening a file,
and reading the contents, which consists of other files. Those
files may be documents or they may be directories (folders)
that again are lists of more files. From my programmer mind set,
I know that each entry must have flags that tell what kind of
"file" this is (document or folder or whatever - we'll get to
"whatever" in a minute) and pointers that get to actual data storage.
But what's the mental image of a non-programmer?
"Magic" is probably the general answer. No clue how it works,
and no interest. Nothing wrong with that, and it may be that
this has become so ordinary and commonplace that there is no
associated imagery: the computer interface itself may be all
that is necessary: click on the folder icon to see more
files and more folders. The computer has become simple enough
that most folks may not even need analogies to understand it.
So now we're back to where we started. How do we, in "plain English",
explain "mount"? Do we need to start with the basics: this is
all just magnetic domains?
Do we need to get into the "whatever" mentioned above, the magical
device files that aren't documents and aren't folders? Maybe,
maybe not. In this case, the person asking was using a Mac and was
actually asking about a ".dmg" file. With Macs, you ordinarily just
click on a ".dmg" (or use "hdiutil attach file.dmg") and a
"whatever" file (/dev/disk1 etc.) is allocated for your use and
melded with the .dmg, a temporary folder is created under /Volumes,
the allocated device is then mounted there, and that's it. More
magic, though of course old Unix folk immediately realize that
something like a loopback had to have happened in the background:
that .dmg got itself associated with a device file somehow. So
now we're in a mess: bad enough that we have to try to explain mount,
but now we need to get into loopbacks? Oh my.
No, we're getting too geeky. Let's try for a visual: imagine
drawing your desktop on a projector transparency. Now let's
draw another desktop on another transparency. Put one transparency
on top of the other so that just one folder of one is on top of
one folder of the other. There's your "mount". Got it?
That may be all some people need. Others are going to
want to get into the details, but the projector transparency image
is enough for a lot of people.
Is that "plain English"? Maybe. It's not enough for a
programmer (but the man page probably was, so that's OK). It
probably puts a reasonable image in the minds of most non-geekish
computer users - most should grasp "mount" from that. Will
it satisfy everyone? Probably not.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Anthony Lawrence
Find me on Google+
© 2010-10-28 Anthony Lawrence