Why does the directory where my LabVIEW executable is located require full control on the folder's security settings to run (Windows XP)?

[CJW1800]

Hi,

I am running Windows XP operating system and I have a LabVIEW 2011 SP1 executable located in a folder in the following directory C:\Rig Name\Program\Unit Name.

I have administrative privileges on the PC so when I log on I can access the executable regardless, however, users do not have administrative privileges.

The application is reading a load of text files and displaying the contents on screen. If the folder, in this example, 'Rig Name' has it's security settings set to read and execute users get a message error 8 file permission error.  However, if I change the security settings for users to full control the application runs as expected.

Why do the security settings have to be set to full control to read text files?

Any help would be much appreciated.

Chris

[PiDi]

How do you open and read those files? Can you provide part of your code that does this?

[CJW1800]

Hi PiDi,

I should have included this on the original post.

Thanks

Chris

[PiDi]

Can you also show screenshot of this folder security settings? Try setting permissions to "Read", not to "Read & Execute" (I'm assuming we're talking about Windows). Also check the file itself - it might have different security settings.

[Wilson54910]

Hi CJW1800,

Have you had any luck in solving your problem?

I know tha this KB is about the error accuring when reading of a CD but the soulution could still be valid and help with your issue.

http://digital.ni.com/public.nsf/allkb/862567530005F09C862565370000BA98

I hope that you find a solution to your problem

[CJW1800]

Hi PiDi, Wilson54910,

Unfortunately I only spend one day a week at the site where I'm having this issue, so I haven't looked at it since Monday.

I'll be there Tuesday next week so I'll update this thread then.

Cheers

Chris

[CJW1800]

HI,

Having looked into this in a bit more detail this morning, using the reference added by Wilson54910, I think I have got to the bottom of it.

The code is pretty old and there is a lot of nested sub VIs and the code that I posted previously wasn't the cause of the error. The code that was causing the error was a function that is not used but still runs, where the Open_Create_Replace File.vi is used in 'open or create' mode.

Removing that part of the code resolved the problem.

Thanks for the input, much appreciated. Sorry I wasted your time with something that was not the cause!

Cheers

Chris