Mapped drives, drive type and UNC in SB7

[Tom H.]

Friedrich,

I'm running the latest SB7 in a VMWare 9 machine with Win7. Three major problems I've run into:

1) I have a mapped network drive in the VM (i.e., folders on host drive) designated as Z:. It is used as a remote data location for my programs, and everything works fine with the program in the VM and data outside it on the mapped drive.

My issue is that the "Get System Info: Drive Type" for that drive always returns $DRIVE_NO_ROOT_DIR$ (value '1'). I've tried 'Z', 'Z:', 'Z:\' and 'Z:\Shared Folders' without any luck.

2) This might be related: When running the installer (actually an update patch), any attempt to copy new/updated data files to my data folder on the mapped drive stops the installation process with an SB7 error that the mapped path can't be accessed or is invalid. The path shown in the message, however, is perfectly correct and valid.

If I change the data location of my program to the UNC path for the data folders rather than mapped, SB7 starts working (writes the files, etc.) My problem, though, is that we have a ton of customers using mapped drives. Which brings up:

3) The 'Get System Info: UNC from network drive letter' function doesn't seem to work either, it always returns the original value, never the UNC representation of the mapped drive letter. I've tried all of the same variations as above (with/without colon, etc.)

Bottom line: Trying to detect if the data folders are on a network drive so I can convert a mapped path to UNC has been a total fail from all angles.

Going crazy -- what am I doing/assuming wrong here?

Thanks in advance,
Tom

[linder]

Hi Tom,

Is that mapped drive accessible at all from an elevated running application? IMO, you have the typical mapped drive UAC issue.

See this:

http://www.lindersoft.com/forums/showthread.php?t=31410

Friedrich

[linder]

BTW, here is a "workaround". But not recommended at all!

Please note that this may make your customers' system unsafe. Microsoft does not support this workaround. Use this workaround at your own risk <g>.

http://support.microsoft.com/kb/937624

Friedrich

[Tom H.]

That's a real catch-22 there -- I can't detect the mapped drive to get the UNC and only the UNC will work, eh? Thanks for the explanation, though.

Question #1: If I use the 'Validate Path' string function on the mapped drive, it appears to work (returns the same path with the mapped drive.) How does that work when other mapped drive type functions fail?

Question #2: Can I trap the "Target directory not writable or accessible" error so that I can handle the situation gracefully?

Tom

[linder]

Hi Tom,

Answer #1: The Handle String Operation function "Validate Path" does not really "connect" to the mapped drive. It just checks if the "form" of the path or file name specification is correct.

Answer #2: What you can try is to use "If File/Folder" Statement to see if the "path" is accessible. Do this before the installer checks the path and you can handle the situation on your own.

Does this help?

BTW, what you can do is to use the "Map/Disconnect Network Drive" function to map an UNC to a drive letter. But then you have another problem. In this case, the elevated running installer created the mapped drive and so your non-elevated running application (asInvoker manifested) can't use it. You can't win this game <g>.

Friedrich

[Tom H.]

Thanks - I'll try using the 2nd option to see if I can detect the mapped drive issue.

You really can't win at this, can you? If you can't see the drive, you can't get the UNC for it. If you don't have the UNC, you can't map it.

Side question: What is the downside of running an installer as 'highestAvailable' or even 'asInvoker'? Just curious.

Thanks again for your prompt help, SB is the best!

Tom

[linder]

Hi Tom,

Thank you for your kind words :-)

"highestAvailable" is just the highest available permission; but in most cases (99%), the user is a Standard User, so that's what is the highest and the installer runs non-elevated (means: no write access to any protected area). A "per-machine" installer always needs administrator execution level privileges (to write to the Program Files folder tree, write to the HKEY_LOCAL_MACHINE registry key, register OCX, etc.).

"highestAvailable" will elevate if the current user is an Administrator. When a Standard User runs the installer, no UAC dialog is shown and the process runs with the standard token. When an admin user runs it, the UAC dialog is shown and setup will run elevated.

My advice is to never use "highestAvailable" for an installer.

Friedrich

[Tom H.]

Friedrich,

New year, old issue...

This came up again, and I think I have a work around but want to run it by you to see if you can spot any potential gotchas.

What I've done is create a small SB8 executable that is manifested as Invoker, which I run non-elevated from within my actual elevated patch script. It has the 'wait' option so the main script pauses during execution.

At that point, since the non-elevated process is running in the users context it can see the mapped drive, parse out the UNC path and writes it to an INI that the elevated installer can then read and use for the rest of the patch process.

So far I've just tested under Windows 7, but it seems to work just fine.

Sound workable to you?

Thanks,
Tom H.

[linder]

Hi Tom,

Yes, this should work fine!

Friedrich