06-14-2016 01:07 AM
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
Solved! Go to Solution.
06-14-2016 02:30 AM
06-14-2016 03:20 AM - edited 06-14-2016 03:33 AM
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.