[VB6] Class: PathLinks - Tame App.Path Under Vista+

[dilettante]

Wouldn't you know it! I introduced a glitch.

Stay tuned for a re-posted corrected version.

[dilettante]

Sorry, duty called. Such is the life when you do contract work on the side!

I regret putting this out there with such fanfare and then pulling the rug out from under it this way. But the bugs that cropped up have been squashed and a few changes (maybe even improvements) were made:

• PathLinks is no longer created as an automatic global object. It really has no use past program initialization and we may as well let the code get unloaded after initial use. The demo has been updated to reflect this.
• There should no longer be a limitation that requires your special folder Public to be on the Program Files drive.
• The glitch that caused things like .MDB files moved from App.Path subfolders to Public subfolders by PathLinks to retain read-only security has been corrected.

Please give it a try to help uncover any remaining bugs and spot any useful missing features.

Thanks.

[dilettante]

Here is a small update. It hasn't changed PathLinks but the demo adds a simple Task Dialog wrapper to display an announcement with the UAC Shield icon. Now if the user Oks this the program reruns itself with elevation.

[dilettante]

I've been wavering on whether to post a corrected version that addresses a couple of bugs. I'm beginning to wonder if it wouldn't be better just to create a 2.0 version that uses CommonAppData and sets the ACL instead of this approach that uses Public.

Since people have looked at what I've posted so far though, it seems only right to put a version correcting some bugs here first.

The biggest flaw in the earlier versions was that it left current directory set wrong even though I had meant to reset it to its original value. That won't happen anymore.


When looking at the demo project, note that the entire "application" is in the Form1 code. Everything else is meant to (a.) set up Common Controls 6.x, (b.) provide Task Dialogs in Vista or later, and (c.) do this "PathLinks" thing.

Version 1.2 above left out Task Dialog support, so it might be simpler to look at even though it still has the current directory bug.

If you want to use 1.3 without Task Dialogs, just change the call to STDlg.TaskDialog() to a MsgBox() call instead. Then remove the STDlg.cls module since you won't be using it anymore. MsgBox() dialogs just look sort of old-timey and Win 3.1-ish on newer versions of Windows.


Using Public instead of CommonAppData did two things: (1.) unlike CommonAppData, Public files and folders aren't hidden which some people see as a bonus; (2.) since Public files and folders don't default to "owner" security unlike CommonAppData, they provide a read/write location for all files and users without the need to alter the security ACL on them.

The second reason was the big one, but a CommonAppData version of PathLinks could handle that.

[dilettante]

Yet another version.

This one corrects a few minor bugs, but more importantly it adds the ability to handle moving and linking to data files in App.Path. Yes now PathLinks handles files in the application's Program Files folder, not just in subfolders under it.


After testing the demo from within its Project folder (i.e. after compiling rather than after creating a PDW Setup and installing it) you'll want to:

• Delete the three symlinks from the Project folder.
• Delete the folder "temp" (and the symlink it contains) from the Project folder.
• Copy the demojunkfile.txt back to the Project folder from the Public subfolder.
• Copy the demojunk folder back.
• Delete the Public subfolder for your application.

When creating a PDW Setup be sure you add a few files:

• The manifest (under $(AppPath)).
• The demojunkfile.txt (under $(AppPath)).
• The somestuff.txt file (under $(AppPath)\demojunk).

The demojunkfile.txt is new for this version, otherwise these rules apply to testing previous versions as well.


Be sure to read the comments at the head of PathLinks.cls, there is some important info there.

For example files to be relocated by PathLinks need to have an extension, because the "." is used to figure out of it is dealing with a file or a folder. This means that folders should not have a "." or PathLinks will try to treat them as files!

We need this because when PathLinks is relocating files and folders those files and folders might not exist yet, so it can't simply test the item for "IsFolder" as you normally would.

[dilettante]

If it helps any, here's a screenshot showing the three files you need to add manually when using the PDW to package the demo project after compiling it.

Be sure to note the Install Location for the somestuff.txt file!

Though the demo never actually uses somestuff.txt it is included here to show that PathLinks moves the file, as it does with demojunkfile.txt as well.

[dilettante]

Ok, here is PathLinks 2.0 that I suggested earlier.

It is roughly identical to PathLinks 1.4 above, with some major changes:

• The list of files and folders provided to PathLinks.Publish() is now relocated to CommonAppData (ProgramData) instead of Public.
• The ACL on the subfolder created under ProgramData for the application is changed, giving Full Control to the Users group.

This is where a program written to "follow the rules" would put its data, and you can have it with no rewrite. All you'd need to do is add the PathLinks class and its related code as previously described, providing the list of files and folders to relocate. Then run your application after installation one time with elevation.

As before, these actions are only taken on Vista or later. Earlier Windows versions don't have a convenient symlink that is easy to manipulate.


Caution:

This code is now setting an ACL in a very sensitive part of the filesystem. It isn't doing anything a proper installer for a properly designed program wouldn't do, but you want to get it right!

The demo was tested to make sure it doesn't screw up, but...

... during development I had a bug and I ended up setting the ACL on the ProgramData folder itself! This required a System Restore (and I was lucky to have a fairly recent Restore Point). Be careful if you tamper with the logic in PathLinks.


When in doubt, try it out.

By that I mean that you'll want to be sure to test your installer and your "first run" on a clean test machine (which you ought to be doing anyway) instead of on a machine you use for normal purposes.

Some sort of VM is usually the most convenient.