From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

windows permissons

Solved!
Go to solution

How about program configuration settings where the app is installed on a single PC and tehre are multiple users like a production test facility?  The program config settings are things like if the PC has multiple monitors which VI pops up into which display type info....

0 Kudos
Message 11 of 14
(694 Views)

Hi id,

 

see Sams comment: he is suggesting the PublicAppData folder, which is accessible for all users...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 12 of 14
(692 Views)

Sam what I am using is the Get System Dir.VI and selecting the Public App Data as the input which results in C:\Program Data on my machine while running the Labview Dev Environment.  My problem is the VI that I wrote when operating in the Labview Dev Environment reads/writes to the C:\Program Data folder which is read only.  The Public App Data folder for my built executable works fine as it is nested under my Apps directory

 

What I gather that you are saying is that this folder may not be able to have its permissions changed due to it being a system folder....so I have to change the permissions manually in the development environment if it is installed on another machine?

0 Kudos
Message 13 of 14
(682 Views)

Hi id, 

 

To test this, I created a simple VI that tries to create/write a text file in [Public App Data] as follows:

16-01-2014 15-55-45.png

 

This VI ran without errors, there was a TestFile.txt in [Public App Data]\TestFolder. Obviously on my development machine I am running LabVIEW as an administrator so it has no problems with file permissions.

 

For the built executable, which will run on a user account without administrator permissions - I was unable to write/create the configuration file in a subfolder in [Public App Data] until I modified my installer to create the subdirectory in [Public App Data], place a dummy file inside it and then unlock the folder. This allows applications running as a user to create/modify files in that folder.

 

This is the same if you try to write to files inside your program's folder in [Program Files] - if you run the application as a user without 'unlocking' the subfolder in your installer you will be unable to modify files.

 

I guess if you don't create an installer, you will need to modify the permissions for that folder manually.

 

As others have said - the only location that users can write to is one of the 'User' system directories (i.e. a per user configuration). If you want to have a system wide configuration then you will need to either unlock the location as part of the install process (installers have to run with elevated permissions so they can change the permissions for you as part of the process) or manually modify the permissions later as an admin.

 

Microsofts recommended practice is to use user specific folders (i.e. [Users App Data]) for everything, but if you need to store system wide configuration (if it really is system side - rather than something that should be down to user preference) then you should use [Public App Data] but to do that you'd need to 'install' the software.

 


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 14 of 14
(675 Views)