Problems only with the Write to Measurement File and selecting Excel as output (.xlsx). It appears that no matter what permissions are set on the directory, LabView ignores the directory permission inheritance rules and creates on owner only structure.

[cmcandrews]

Having multiple users that will logon and run this application, I am having problems only with the Write to Measurement File and selecting Excel as output (.xlsx). It appears that no matter what permissions are set on the directory, LabView ignores the directory permission inheritance rules and creates on owner only structure. This prevents anyone from opening the .xlsx file and shows it as possible corrupt. Which it isn't. This is a Windows 7 system with no Bitlocker, but the Excel icon on the files that the user can open has a padlock on it. Any other file I create (LVM, TDM, TDMS) all inherit the directory permissions. Only the .xlsx file are written with strict owner permissions. WHY?

[Taki1999]

Check out this forum post.

Write to Measurement does some quirky things when it generates Excel files. It would not surprise me if the ActiveX steps it is taking result in generation of files with incorrect permissions.

That's my guess as to why.

Workarounds are probably going to point to using something other than Write to Measurement. Any particular reason why you're doing .xlsx instead of text or some other binary format?

[cmcandrews]

I was using it because it supposed to be clean and simple.  Reading that other post you guided me to, I see that there are other poorly implemented issues with the Excel format VI.  I was going to try and drill down into it, but it may be worth my time to just write it out to a text CSV.

It would be clean to give this data in a spreadsheet cleanly as it does, but if multiple people log on to this system and write this data out, then no one can read it without Admin privileges to take ownership.

I did open a support ticket, since I think the NI team should put some attention into a function they provide.  I'm sure the Microsoft Office add-on works fine, but I see no need to purchase.

Thanks for your suggestion, and perhaps someone else has run into this issue.

[Bob_Schor]

---

@cmcandrews wrote:

I'm sure the Microsoft Office add-on works fine, but I see no need to purchase.

---

Well, perhaps the RGT (which, by the way, is now standard in LabVIEW 2014 and higher) had a "need to purchase" because it worked better, and the addition of the .xlsx output to "Write to Measurement File" bypasses Excel and creates the file in another way that "locks" it to the user.

Bob Schor

[cmcandrews]

I.m still working on an anwer with NI Technical Support, however, it appears to be only in certain directories:

1. Under my Program(x86) application directory. Where I have a sub-data and reports directories
2. Under Public Documents (a company synchronized directory)

I don't get this problem if I create a new directory off of C:\, or if I write the data into the company's shared network directory.

It may still be a Windows 7 security management problem coupled with how LabView creates it's .xlsx files.  I tried to drill down into the code, but I didn't personally see anything that may be allowing the override of the parent directory security.

[Bob_Schor]

We read and write Excel files all the time using LabVIEW and the RGT.  In our case, when we read/write data files and want the permissions to be for "All Users", we store them on a separate Data "Disk" (it is actually a Data Partition, with its own Drive letter, on the System Disk).  By default, the Security Permissions on this disk is that "Authenticated Users" have "Modify" and related privileges, so all files and folders (specifically, our data folders) inherit this set of Permissions.

The Permissions on C:\Program Files (x86) are much more restrictive, basically "No Writing Allowed" (with limited and specific exceptions).  Similarly, on my system, the root of the Public Directory is also, by default, somewhat restricted compared to our Data Disk.

Bob Schor

[cmcandrews]

I would agree with the stricter sedcurity, however, it is only when LabView write an .xlsx does it forget the parents permissions and alway write access for only three type: SYSTEM, My account, and Administrators ( a funny note is that even administrator cannot open the .xlsx file even with his privileges.)  Only the owner can open within Excel.

Any other file type written by LabView into these directories inherit the parent security structure and everyone can freely open these files.  My solution for now is writting it to another directory outside these zones, but I wanted to keep thing neat and in one place within the Application "environment".

[Bob_Schor]

---

@cmcandrews wrote:

however, it is only when LabView write an .xlsx ...

---

But LabVIEW does not write an .xlsx file.  LabVIEW (politely, I hope) asks Excel to write it.  How the two of them negotiate for permissions is, I admit, a bit tricky and mysterious ...

However, you do have a work-around that "works", and NI knows there is a potential issue ...

Bob Schor

[cmcandrews]

So under the Write to Measurement File.VI when .xlsx is selected you will see:

This sets up the file and calls the Write Data All:

This then creates the file with:

WRITE EXCEL (CREATE):

Creates a binary file:

and write meta data:

I don't think it does any communication with MS Excel, but creates a formatted Excel binary file.

[SFK · Accepted solution]

Hi everybody,

I have run in the same issue of not being able to backup XLSX files written trough the Express VI (access denied), but thanks to your breadcrumbs, I have discovered the reason and a solution:

LabVIEW does not write the XLSX file "in one go" into the target directory, but (as one can see from the screenshot in cmcandres post above) only verifies being able to write a file in the target directory by opening, closing and deleting the target file. It then creates a temporary folder under the "Temporary Directory Function" output directory, which relates (if not overridden in LabVIEW's settings) to the user-specific Windows User Environmental Variable temp path, puts all data, metadata etc. there, zips the contents and moves the zip file to the target directory while renaming it on the move.

So there you go: the ZIP file inherits the access rights of the user's TEMP directory, and those rights are kept during the move.

Two solutions derive from that situation:

(a) as an administrator, reroute the users' TEMP directories to some folder outside the c:\user\ hierarchy, e. g. c:\temp\ through Windows' Control Panel (System » Advanced System Settings » Environmental Variables... » "TEMP" and "TMP" user variables and set the c:\temp\ folder's access properties to full control for everyone (reboot after applying these settings), or

(b) in your LabVIEW code, use the "Filename out" output of the Express VI to copy the XLSX file to a new file name in your target folder, delete the original file with the quirky access properties and then rename the copy to the original filename. The copied file will inherit the target folder's access rights, so the target folder must have at least "list contents" and "read" permissions for everybody who needs to access the files afterwards.

Best regards,

Sebastian