The Problem is "Obvious"QA's Sucker-Punch

Many years ago when I was in college studying Calculus, the professor had a favorite line:  "It is intuitively obvious that. . . ."

He'd fill the blackboard with mathematical hieroglyphics that would give Einstein headaches, say "It is intuitively obvious that [something or other]", turn back to the blackboard and perform some seemingly magical manipulation whereupon the entire mess would collapse on itself with the answer being something like three and a half.  Needless to say this left the rest of us looking at each other like something had just zoned-in from The Outer Limits, thinking "What the !!! was that?!"

Sherlock Holmes, in one of his stories, (I forget which one), made a very pithy comment when he said "There is nothing more deceptive than an "obvious" fact"

This is a statement that should be permanently tattooed onto the palm of every QA individual in the world.

If I were to write a "Ten Commandments" for QA, part of it would be those words that should strike fear in the heart QA engineers and testers all over the world:

• Always
• Never
• Every
• Only
• Assume
• Obvious

I am sure there are others, but I just don't remember them right now.

Why are these words a problem?  Because these words are the flashing red strobe lights that warn us about assumptions involved in design, requirements, or test, and we need to remember that these assumptions may not be true all of the time.  In fact, they may signal a special case that is "assumed" to be true all of the time, or that something seemingly obvious to us is obvious to everyone else.

And THAT lies at the heart of QA's biggest failures.  It's like a politician looking you straight in the eye and saying "Trust me!"

In it's purest essence, whenever you hear a broad blanket statement about something or other, it signals a potential weakness that should be given extra scrutiny during test or verification.  In other words, we should be continually vigilant toward the "obvious", be it in requirements, design, or verification of what we do.

What say ye?

Jim (JR)

You Can't Get There From Here!Mapped drives are not visible from anelevated command prompt

This is another one of those "What WERE they smoking?" type of tech-tips.

Issue:
You are using either Vista (ye Gods!) or Win-7.
You have one or more mapped drives to external/networked resources.
You open an elevated command prompt and attempt to do something that requires access to the mapped drive.

Zzzzzzzzt!  "We're sorry, but thanks for playing!"

You will notice, rather rapidly, that "you can't get there from here" - that is, the command prompt window cannot see any of your mapped drive letters.  To be brutally honest about it, the command window CAN see the mapped letters. . . . it just won't let YOU have them!

(Note that there are reports from people saying that this won't work from a non-elevated command prompt too, but others claim that this is not an issue.  Your Mileage May Vary.)

If you search the Web you will see a mighty wailing and gnashing of teeth, with people waiting in line to beat Microsoft senseless over this issue.

There are two workarounds for this issue - though, in my opinion, these are UGLY hacks for a lack of functionality that should exist by default.

• From an elevated command prompt, execute:
  net use [letter:] \\[system]\[share]
  Note that you cannot use the pre-existing mapped drive letter.  The command prompt won't let you use it by default, but complains if you try to map it within the command window.  Go figure!
  (Ref: http://tinyurl.com/6xlk664 - near the bottom of the page)
  
  
• You can edit a Registry key:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  by creating the a DWORD value of EnableLinkedConnections and setting it to "1"
  Though this works, sources at Microsoft claim that it opens potential security holes to cleverly written malware.
  (Ref: http://tinyurl.com/5sunjbb)

For those of you who are more paranoid about security, or if you want to write batch-files that are portable, I would suggest the first solution.  Otherwise, you can make the registry edit and take your chances.

To read all about it, along with Microsoft's response, here's the referenced article, http://tinyurl.com/5sunjbb
that discusses this issue in detail.

Sigh. . . .  You're damned if you do, and damned if you don't.

What say ye?

Jim (JR)

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)