Welcome to the QA Tech-Tips blog!

Some see things as they are, and ask "Why?"   I dream things that never were, and ask "Why Not".  
Robert F. Kennedy

“Impossible” is only found in the dictionary of a fool.  
Old Chinese Proverb

Wednesday, November 2, 2011

Don't Shoot Yourself In the Foot!
(Protecting 'Nix mount-points)


One of the big differences between Windows and the various 'Nix flavors is in the way it handles mounting logical/physical drive volumes.

Windows uses "Drive Letters", (C:, D:, etc.), to distinguish between mounted drives.  Because of this, it's relatively easy to know where one drive or partition ends and another begins as they are shown as separate, distinct entities.

On the other hand, 'Nix uses "Mount Points", ("/mnt/foo", "/mnt/bar", etc.), to distinguish between mounted devices.  Because of this, devices, data-sources, or whatevers, appear as if they are a part of the local, physical hard drive - yet can be located on a different partition, different hard-drive, a different computer, or it could even be located in an entirely different part of the world.

The way this works is like this:
  • You create a physical directory where you want your data-source, (hard drive, partition, etc.), to appear; such as "mkdir /mnt/foo" where "foo" is now an empty directory located within "/mnt" (or wherever you want to put it).
  • You then actually put the physical device on top of the mount point by "mounting" it:
    Viz.:  "mount [something on] /mnt/foo"
And Voila!  Whatever data, device, or whatever exists at or within "something" magically appears at "/mnt/foo" replacing whatever was already there.

Are warning bells ringing yet?  They should be. . . . .

What this means is that - if you change directories to "/mnt/foo" - you have no way of knowing if your [something] is, or is not, mounted there by simply looking at the directory.  That is, unless you just happen to know what's supposed to be there. . . .  An assumption I'd really hesitate to make if I were you.  Especially if you are starting out with an empty "something".  Or if the errant user thinks he is starting out with an empty "something". . . . .

What this also means is that shell-scripts, (batch files for all you Windows aficionados), have no way of knowing what's there, or what's supposed to be there, without you telling them somehow.

(OK, OK!  There are special commands that you can run to find out what's there, or what's not there - but they are not always easy or intuitive, and it's really easy for an unknowing user to dump stuff into a mount-point that's not mounted yet.  Go ahead.  I dare you.  Ask me how I know. . . . .)

What Unix should do is make un-mounted mount-points un-writable in the same way that Windows/DOS doesn't allow you to use a drive letter that is not yet mounted.  But it doesn't.  Any Tom, Dick, or Harry can blithely write into an un-mounted mount-point, causing no end of confusion.

Solving the Problem:

Obviously what is needed is some way to show when the directory you are using as a mount-point - isn't mounted.  And the hint on exactly how to solve this problem is given by the problem itself.

If you remember, when you mount something on top of a directory, (which, by the way, is the way it works), whatever was in the directory prior to being mounted disappears, replaced by whatever you mounted there.

The fix is to deliberately put something in the mount-point directory - prior to something being mounted there - warning everybody that whatever is supposed to be there, isn't there yet.

So. . . . this is my fix:

From a root terminal - or sudo root. . . .
  • I create the directory where I want to mount something.
  • I deliberately "touch" (create, with nothing in them) two bogus files with warning file names:
    Viz.:
    touch 'Do Not Use!'
    (and)
    touch 'Not Mounted Yet!'
  • I then "chmod" these two "files" to 644 - making them read only to everyone but root.
(Note that the single quote marks are not a mistake.  You need to use them to include the "!" character in the file's name - as normally the "!" is a "magic character" in 'Nix.)

With this, there is no possibility for mistake.  Anyone who goes to that directory, expecting something to be there, instantly knows that - whatever it's supposed to be - it isn't there yet.  And depending on the system - and their relationship with it - they can either go "Oops!  Forgot to mount my. . . .", or put the Sysadmin wise that something isn't exactly kosher in Denmark.

What say ye?

Jim (JR)

3 comments:

  1. Some would say that the Windows view of mounted drives is the "wrong" one, and that the 'Nix Unified Filesystem approach makes the most sense because it makes the presence or absence of mounted drives completely transparent to the end user or software. I would guess that, in most server environments, the fstab or automount configuration is relatively stable, making this pretty much a non-issue. Nowadays, however, we see 'Nix systems in non-server uses, where swapping out flash drives and CDs and the like is more common. For these environments, this tip is a good idea. It might be worth noting that for many mountable devices there is a "lost+found" directory in the root of the filesystem, so if you see /mnt/device/lost+found then the device is mounted, but if you don't then it isn't.

    ReplyDelete
  2. Bennette,

    You are absolutely right, as usual. (:laughing:)

    However. . . .

    Even sysadmins have their "2nd cup of coffee" brain-dead days, and (IMHO) if a 2-step process can help someone from making a total ass of themselves, it's worthwhile.

    What say ye?

    Jim (JR)

    ReplyDelete
  3. Oh, and one other thing. . .

    You said:
    (quote)
    Some would say that the Windows view of mounted drives is the "wrong" one. . .
    (/quote)

    Some religions - even different flavors of the same religion - claim that the others are "wrong" too. And IMHO that brings us back to the "Atari vs Commodore" system wars again.

    Depending on the user, and the use the system is being put to, I can see advantages and disadvantages to both file system types.

    Does it really matter? AFAIK, sometimes a screwdriver works a lot better than a hammer - and different filesystem structures work for different people for differing reasons.

    My thought is that the system should fit the user and the use - and if there's a way we can help a potential user avoid an inadvertent pitfall - then that's the whole idea.

    What say ye?

    Jim (JR)

    ReplyDelete

Thanks for sharing your thoughts here at the QA Tech-Tips Blog!

Note:
This blog will not, repeat NOT, publish comments that contain ANY KIND OF HYPERLINK.

If your comment contains ANY KIND OF HYPERLINK it WILL BE DELETED.

Please read the article at How To Get Comments Approved On This Blog for additional information regarding this rule.

Thank you for understanding.

Jim (JR)