curdrive() returns empty; curdir() returns UNC name of drive

[Cliff Wiernik]

In my normal application, on my Novell/Microfocus OES shared drive, curdrive() returns "G" and curdir() returns "\fca\data".

In a small utility application I am writing, on the same environment, curdrive() returns "" and curdir() returns "\\servername\volumename\fca\data".

The same think happens if I pull up xdot from inside the application and type the functions into the command line.

Has anyone seen this and why it is returning the UNC value for the directory and a empty string for the drive.

[Piotr D]

Hi Cliff,
please check property of the program - probably if you click with right button of mouse on the program icon, then "Properities" and
"Advanced settings" you have check "Run as administrator". In this case the application don't see drive mapping.

Piotr

[Cliff Wiernik]

I am not running at a program icon. I am running from the command prompt for testing. Within that prompt I can access the drive mapping and see the drive mapping.

[Piotr D]

Cliff,
the normal application is running from icon? Please check with windows explorer properties of the second program. And how you run command prompt box - mayby here "as administrator"?
What version of Windows you have?
Piotr

[Cliff Wiernik]

Both programs can be run from the command prompt or an icon. For testing, I am just executing the command to run the program from the command prompt in both instances. It has nothing to do with administrator properties as if it was the case, I could not have a connection to the network share. We have ADS on the network and also a developer version on the workstation. Never any problems before.

However, I did notice that with the new small application, it also, when run on the c: drive cannot find the xbase++ 2.0 runtime via the path command. I had to copy the runtime to the folder for the application exe was located. So I suspected that something wierd is happening but cannot see it. I will have to look at the project file and other things. I use basically the same setup for everything and have other small similar application that do not have this problem. Hunting it down is wierd. From within the application, even if I use Alt-D to popup up xdot, when it shows normally the drive\directory in the format g:\fca\data it now shows \\\oes-main\VOL1\fca\data. It is wierd.

[bwolfsohn]

Cliff,

try running path and net use from inside the program and redirect it to a file. that may give you a clue..

[Cliff Wiernik]

What is the purpose of doing net use from within the program. It is already mapped via the network login script. And I have access. I can do a directory of the drive and it is active. it provides information, but it is the unc. The other program does not. I have many programs, some CRT, some GUI that all use the same dbesys() and curdrive()/curdir() return the expected values, not UNC components.

[bwolfsohn]

just looking for clues cliff.. just looking for clues...

[Cliff Wiernik]

What it appears to be is the sample new program file name, fileupdate.exe or fupdate.exe. If you change the name of the exe to filefile.exe, it works as expected. I don't know what is intercepting it, but I tried all 3 names and the executable is identical according to windows comp.exe. Only the name is changed. Really wierd. I am waiting on a reply from Andreas related to this new info prior to doing some sysinternal checking on it. What is really wierd is that when the file name is fileupdate.exe or fupdate.exe it cannot file the runtime support files that are in the path command. Really wierd.

Brian, thanks for your suggestions. Did not know if you had seen something that your comments may point to. It is really wierd though. Worked on my c: drive other than not finding the runtime files in the path.

[Cliff Wiernik]

The problem was that this is a file structure checking and update program. I called the program fileupdate.exe. Windows detects any 32bit program with a portion of the file name being "install", "setup", "update" and possibly other similar ones as install routines and elevates the privileges. I had UAC at the lowest level so did not see this and it automatically elevated privileges, disabling the path and network direct access. That caused the problem and simply renaming the file fixed the problem.

Go info in case someone else encounters this.