#1 App creates C:\Program file

open
nobody
None
5
2005-09-14
2005-09-14
No

Hey guys. Nice work on this project. Glad to see
Google's Summer of Code producing some really nice
utilities.

Now, unfortunately, the bad news. I believe Nmap GUI
is creating a file named 'Program' at the root level of
the C: drive, and this is "a very bad thing".

First, background.

Last night I tested out this GUI on one of my machines.
As it has no installer, I simply took the .ZIP file,
decompressed it so that the files were stored in
C:\Program Files\NmapGUI\.

This particular machine also happens to act as a bit of
a server (syslog, Apache2, MRTG graphs). Today I come
in to find that I have no graphs and the system is
acting flaky as heck. I check the logs and note that
MRTG started having trouble right after it was
scheduled to restart (I have a script to do this daily
as we've had hang issues if MRTG was left running for
weeks on end). I eventually reboot the server, at
which point I get one of the stranger messages I've
been hit with:

__________
“There is a file or folder on your computer called
“C:\PROGRAM” which could cause certain applications to
not function correctly. Renaming it to “C:\PROGRAM1″
would solve this problem. Would you like to rename it now?”
__________
The options are [rename] and [ignore].

Of course, being quite leery, I choose [ignore] and
begin looking around. I notice the only folder is
named "C:\Program Files", as it should be.
(Unfortunately, I did miss the FILE named 'Program'
initially.) I have had issues in the past with file
shares and various file system issues where, for some
inexplicable reason, Windows has gone brain dead and
seen things only with the old DOS 8.3 style filenames.
So the last thing in the world I wanted was for
Windows to go renaming what was actually the "Program
Files" directory to something else and potentially
hosing my setup.

Long story short, after much Googling, reading, and
digging around, I finally realized there WAS a file at
the root of C: named 'Program.' *sigh* And as it turns
out, just as in Windows XP you cannot create a
file/directory named "COM1" or "LPT1" due to legacy
issues dating back to DOS (go ahead, try creating a
directory named each of these...interesting results
occur...and inconsistent ones no less), it appears that
if you have a file/directory at the root of the system
drive named "Program", it can freak out Windows as it
has issues when searching the PATH. (I had a heck of a
time tracking this down as some of my Windows services
like Apache2 ran just fine after a reboot, whereas Kiwi
Syslog Daemon and FireDaemon did not. As it turns out,
Apache2 passes parameters to its executable, so the
pathname for the app itself is in double-quotes,
whereas neither Kiwi nor FireDaemon do so. These
double-quotes made it possible for Windows to find
Apache2 but not Kiwi or FireDaemon, amongh others.)

Anyway, the C:\Program file was created right around
the time I put Nmap GUI on the box and gave it a run,
and I haven't done any other work that was new in the
past few days.

Using a text editor to view C:\Program, it appears it
is an XML file and odds are there's a goof in the code,
as the beginning of the file starts with

__________
<?xml version="1.0" ?>
<?xml-stylesheet href="nmap.xsl" type="text/xsl"?>
<!-- nmap 3.84ALPHA1 scan initiated Wed Sep 14 17:37:37
2005 as: nmap -oX C:/Program 127.0.0.1
Files/NmapGUI/templog/scan62 -->
<nmaprun scanner="nmap" args="nmap -oX C:/Program
127.0.0.1 Files/NmapGUI/templog/scan62"
start="1126733857" startstr="Wed Sep 14 17:37:37 2005"
version="3.84ALPHA1" xmloutputversion="1.01">
...
__________

Note I ran NmapGUI against my loopback (127.0.0.1) as a
test. Looking at the XML tags, notice the 3rd and 4th
lines. The IP address is embedded in the middle of
what should be the path "C:/Program Files/...", which
instead reads "C:/Program 127.0.0.1 Files/...".

Again, note I had Nmap GUI installed in C:\Program
Files\NmapGUI.

I moved the app to C:\NmapGUI and ran again, and beyond
noticing now that it doesn't allow for testing the
loopback, it ran much quicker and did NOT create a file
called C:\Program. It appears this application has
issues with being located in a directory structure
containing a space in the path back to the root.

Just thought you might like to know, either to document
that users do not place this application in such a path
situation, or possibly to give you insight into where
to look in the code to handle that situation.

Discussion


Log in to post a comment.