LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get Permissions Vi reliability - Windows 7

Solved!
Go to solution

Sometimes I get wrong results from Get Permissions VI on Windows 7

 

The VI reports I don't have the rights to write in a folder, but I can.

For instance I got "101101101" for C:\Users, but I can.

 

Why does it happen?

 

Is this because as a user I cannot write in C:\Users, but as a member of the group Administrators I can?

 

As the Help says "Use of the permissions parameter is very limited on non-Linux operating systems",

but this could make Get Permissions Vi completely useless on Windows.

 

Marco

 

0 Kudos
Message 1 of 3
(3,547 Views)
Pretty much, yes. Given the constantly moving target that windows file permissions is, there is not a whole lot that NI can do. So only write files to locations for which you know you have write permissions. LabVIEW has a built-in function that will return common Windows paths like the User desktop or temp directory.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 2 of 3
(3,525 Views)
Solution
Accepted by topic author MarcoMauri

Windows has two different systems that control access to files. The first is a simple boolean attribute that specifies if a file is write protected or not. This is a DOS relic and what Get Permission basically returns. The second is the ACL based security system that Windows NT introduced (borrowed heavily from the DEC OS). That's where your Administrator and non-Administrator accounts etc come into play. Get File Permission does basically nothing with this information as it is rather difficult to interface to from a user application and notorously badly documented.

 

Windows itself isn't always consistent in how it treats these two things. Explorer itself does all kinds of involved tricks to get around these problems but fails sometimes short too. At the time LabVIEW was ported from the Mac to Windows and Unix, the write protection flag was all that Windows did support. The Unix access right system was simple but did support a fairly fine grained separation into users, groups and everyone with read, write, execute flags for each of these groups. On the Mac it was a tiny bit more involved than on Windows but not as full featured as Unix. So the Get File Permission was modeled around the Unix system that allowed for the most features and the others were adapted to fit in there, which for Windows simply meant that anything than write protection of files was not available.

 

The newer NT based access control system doesn't fit at all into this interface and trying to shoehorn it into the Get File Permission node is simply not a feasable option. And changing it into a much more complicated node that can handle all the NT security features hasn't apparently come up as a high priority feature so far. Add to that, that such an interface would be difficult to understand for most LabVIEW users as even system administrators nowadays struggle with it and you can see why there hasn't been much of an effort on this so far.

 

You could argue that it is a bug, but then the bug is in the Windows API function GetFileAttributes() which doesn't really take into account the access control lists of a file in respect to the current user when determining the write protection status of a file. 

Rolf Kalbermatter
My Blog
Message 3 of 3
(3,516 Views)