08-06-2010 11:27 PM
I far prefer to have things like config and ini files residing in the directory with the application. I don't see any reason why I shouldn't have write access to the folder that the app is installed in. Here's your opt-out code:
CACLS "\Program Files (x86)\Application Folder\" /E /T /C /G "Users":F
throw that in a .bat file, add it to the project and have it run after install. You can even replace the path with %1 and use something like [INSTALLDIR] as the command-line argument in the install builder.
08-07-2010 01:37 PM
@blawson: I'd advise against overriding the directory write permissions. The reason is that (for example) a virus scans the /program files/ directory, finds an application folder it can write to, and injects an exploit (maybe a glitch in .ini file handling, maybe even modifying your .exe binary to include a little bootloader) and then WHAMO - your user opens your program and infects themselves with a virus.
And then they'll blame you for it 😞
-Dan
08-09-2010 06:56 AM - edited 08-09-2010 07:03 AM
Excellent response Waldemar, if I could've given you 2 Kudos I would've! Indeed I did find these paths in the Widows7 registry, and also in the Windows XP Registry! This is perfect, exactly what I needed... a robust way to get these paths that is OS independent without having to upgrade to LV 2009. Very helpful notes on what the ideal use of each of these paths might be too. Thanks for taking the time to respond.
-Anthony M.
08-09-2010 07:20 AM
Waldemar,
One question about a line in your post:
"It is normal that the user has full acces to the last for paths and read access to the first path."
What exactly do you mean by this? Will the user have write/read privileges to all the paths you listed in your post?
Thanks again!
-Anthony M.
08-09-2010 08:11 AM
I also found a very helpful solution here using Win32 calls:
http://decibel.ni.com/content/docs/DOC-2015
-Anthony M.
08-09-2010 08:19 AM
Hi Anthony,
Here's the .NET function in LabVIEW 8.5 - it works in all versions of LabVIEW and all current versions of Windows (inc 64 bit versions) and is a pretty simple VI as well. 🙂
Shaun
PS. Using this method also adds in some future proofing in case MS decide to do funky things with the registry in future OS versions.
08-09-2010 08:23 AM
Great! Thanks Shew, I will check it out.
-Anthony M.
08-10-2010 06:11 AM - edited 08-10-2010 06:12 AM
Anthony,
all authenticated users have full access to the <username> \Appdata folder and <username>\Data folder. This means he can create, read, write and delete files and folders.
For the All users\Appdata folder and All users\Data folder he has Read, Execute, Write and List folder contents rights.
If you install the application under Program Files he only has read rights for this folder.
In my last post there is a typo "last for paths" should read "last four paths" otherwise the sentence makes no sense.
08-10-2010 07:03 AM
Thanks a bunch skew, this .NET vi works like a charm. I will surely be using this. Thanks to everyone who gave some input on this issue, I have a few methods in my toolbox now for programmatically finding paths on Windows.
08-10-2010 09:20 PM
amaglio: Sorry for the delayed response. Hmmmm...no default data dir in v8. Hopefully someone else helped you with that.
As for registry keys, I use these for programs that I write that interact with files on the hard drive. For instance, I may have an application that graphs data files for my users. I want my users to be able to double-click on a data file and have my application automatically open (if it isn't opened already) then present the data. I also like to set a default file icon for these data files that I created so that users can easily identify the files that load in my software. You know, like how .txt files open in Notepad ;). I use the registry for that.
I prefer to not use the registry for non-windows-environment configuration data. Idk, seems like this is abused by programs too much and is part of what slows Windows down in the long run. I don't know for sure though...thats my theory anyway.