topic Re: windows permissons in LabVIEW

windows permissons

id — Wed, 15 Jan 2014 16:56:17 GMT

Hi I have an issue with my LV App being able to write to a directory that may be set as read only. IS there any way to check and if so, change the permission of this directory from Labview?

Re: windows permissons

Pankajusic — Sat, 31 Jan 2026 21:59:44 GMT

Please go thorough the link : https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/setting-permissions.html

I think this might slove you problem..

Thanks

Re: windows permissons

0utlaw — Sat, 31 Jan 2026 22:00:09 GMT

Hello id,

I believe you're looking for the Get Permissions function in the Advanced File I/O palette:

LabVIEW Help: Get Permissions Function

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/get-permissions.html

Regards,

Re: windows permissons

id — Wed, 15 Jan 2014 20:40:33 GMT

Thanks, but the set permissions VI doesnt seem to work. See attached. After executing this code, this is what the windows dir permissions look like - they are unchanged. Is there something else that I must do before this or something?

Re: windows permissons

Wart — Wed, 15 Jan 2014 21:19:39 GMT

I'm not sure if Set Permissions works recursively on every folder inside of ProgramData. Even if it does, setting all of Program Data to be writeable by anyone is a bad idea. At most you should be setting only the folders inside of ProgramData that you own as writeable, eg. C:\ProgramData\MyApp.

Since ProgramData is a system folder you may not have the permissions required to set it and everything inside to be writeable. Try with a subfolder and see if you don't have better luck.

Re: windows permissons

0utlaw — Wed, 15 Jan 2014 21:36:46 GMT

Hello id,

I ran a few quick tests and the function looks to be working as expected, but remember a few things:

1) The set permissions function isn't recursive. If you want to alter the permissions of all files contained in a folder you'll need to do it one at a time. I'd be surprised if there isn't an example around that already does this, but if you need to create it yourself it should be as easy as using the recursive file list function, also available in the advanced File Functions palette.

2) The LabVIEW development environment or a LabVIEW-built executable may not have permission to modify the settings of certain files or folders depending on their security settings. Top-level OS directories and their contents are likely protected.

In the screenshot you provided (thanks for that, by the way!) it looks like the folder is flagged as having some read-only contents. This is what I'd expect after setting the folder's permissions.

Re: windows permissons

id — Thu, 16 Jan 2014 14:25:28 GMT

Thanks I already did and it did the same - no change to the read only. I have program xml support files in C:\program data under its own folder because thats what the NI help desk told me to do. When I install the program on a new PC, I need to set permissions on this folder so I can read/write to it during program operation.

Re: windows permissons

id — Thu, 16 Jan 2014 14:27:19 GMT

Tom if Labview cant set the permissions of a folder, how can you create an app that has data files that are written to or read?

Re: windows permissons

GerdW — Thu, 16 Jan 2014 14:37:57 GMT

Hi id,

when it comes to Windows behaviour you should ask Microsoft and not NI.

MS suggests to use UserAppData for your program settings. In this folder the current user always has write permissions! Usually it is located in "users\username\ApplicationData\Local" (or similar, don't have Win7 at hand)...

You can find that folder very easily:

Re: windows permissons

Sam_Sharp — Thu, 16 Jan 2014 14:40:33 GMT

I had the same problem - I have a couple of related applications that need to share & read/write to a configuration file in [Public App Data]\MyApp.

The solution that I found is that I had to include a file (I used a placeholder file) inside the [Public App Data]\MyApp in my installer and then tick the 'unlock' option on that folder. After the installation is complete, my applications can then read/write files inside the [Public App Data]\MyApp folder.

I think the reason for the placeholder file is that without it, the 'Unlock' setting of the folder does not seem to apply correctly.

I don't think this is a problem if you use a user-specific location (such as user appdata).

Re: windows permissons

id — Thu, 16 Jan 2014 14:41:09 GMT

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....

Re: windows permissons

GerdW — Thu, 16 Jan 2014 14:43:56 GMT

Hi id,

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

Re: windows permissons

id — Thu, 16 Jan 2014 15:30:02 GMT

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?

Re: windows permissons

Sam_Sharp — Thu, 16 Jan 2014 16:17:45 GMT

Hi id,

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

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.