How can I deny write access to datalog files for all but one process in LV8?

[Larry_Stanos]

In LabVIEW 7.1, wiring the deny mode terminal of Open File.vi with a Deny Write Only enum constant was an effective means for ensuring that only one process could write to a datalog file at a time.  In LabVIEW 8.0, Open File.vi is no longer available and the new Open/Create/Replace Datalog vi does not provide a deny mode terminal.  Also, the new Deny Access vi does not support datalog files.  Furthermore, the Set Permissions vi is an unsatisfactory solution because under the Windows operating system, it simply sets the Read Only file attribute.  This is inadequate because I have demonstrated that it is still possible for two processes to open a datalog file with read/write access before either one has had a chance to set the Read Only file attribute in order to lock out the file.  If a process sets the Read Only file attribute first, then it can't open the file with read/write access for itself.

Does anyone understand the file mechanism by which deny mode used to work with the old Open File.vi?  I wish to restore the functionality I had in LV 7.1 in my LV 8 programs.

Thanks!

Larry

[rolfk]

---

@Larry Stanos wrote:

In LabVIEW 7.1, wiring the deny mode terminal of Open File.vi with a Deny Write Only enum constant was an effective means for ensuring that only one process could write to a datalog file at a time.  In LabVIEW 8.0, Open File.vi is no longer available and the new Open/Create/Replace Datalog vi does not provide a deny mode terminal.  Also, the new Deny Access vi does not support datalog files.  Furthermore, the Set Permissions vi is an unsatisfactory solution because under the Windows operating system, it simply sets the Read Only file attribute.  This is inadequate because I have demonstrated that it is still possible for two processes to open a datalog file with read/write access before either one has had a chance to set the Read Only file attribute in order to lock out the file.  If a process sets the Read Only file attribute first, then it can't open the file with read/write access for itself.

Does anyone understand the file mechanism by which deny mode used to work with the old Open File.vi?  I wish to restore the functionality I had in LV 7.1 in my LV 8 programs.

Thanks!

Larry

---

I think the lack of support for Datalog Files of the Deny Access function is an oversight and therefore a bug in LabVIEW 8. As to the situation where you have to reopen the file through the Deny Access function as the online help for that VI states, this feels and sounds like a step backwards. I saw no problem with the deny access mode being specified at the time of the Opening of a VI and if you really need to change the deny mode later on you always could do the explicit close and reopen yourself.

Rolf Kalbermatter

[Larry_Stanos]

I appreciate the empathy from Rolf, but I'm hoping that someone may have written one or more vi's containing CINs that call Windows 2000/XP file access control library routines.  At least I'm assuming that is how the deny mode input to Open File.vi used to work in LV7.1.  The Microsoft Developers Network on-line documentation on Access Control http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/access_control.as... is daunting to put it mildly.  But even if a set of CINs has not already been coded, perhaps someone could point me to the specific set of calls I need to make to absolutely guarantee that no two clients can simultaneously open the same file with write privileges.

Unfortunately the elimination of deny mode functionality for datalog files in LV8 has sabotaged my commitment to a March 1 release date because it would also be impractical to convert everything back to LV7.1 at this point.

Sincere thanks to anyone who can help me out here!

Larry

[rolfk]

---

@Larry Stanos wrote:

I appreciate the empathy from Rolf, but I'm hoping that someone may have written one or more vi's containing CINs that call Windows 2000/XP file access control library routines.  At least I'm assuming that is how the deny mode input to Open File.vi used to work in LV7.1.  The Microsoft Developers Network on-line documentation on Access Control http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/access_control.as... is daunting to put it mildly.  But even if a set of CINs has not already been coded, perhaps someone could point me to the specific set of calls I need to make to absolutely guarantee that no two clients can simultaneously open the same file with write privileges.

Unfortunately the elimination of deny mode functionality for datalog files in LV8 has sabotaged my commitment to a March 1 release date because it would also be impractical to convert everything back to LV7.1 at this point.

Sincere thanks to anyone who can help me out here!

---

Unfortunately the functionality you mention does not work in the way the deny mode in the LabVIEW nodes works. Basically that deny mode is converted to an according FILE_SHARE_READ/FILE_SHARE_WRITE value and passed to the Win32 API CreateFile function. This is more or less the only place where you can define a global share (or deny) access to a file. That is also why the Deny Access node online help is talking about that the file is reopened.

But I just retried what you had tried to do, and low and behold it works with wiring a datalog refnum to Deny Access. What is important here however is that you do need to wire a datatype to the record type input of the Open/Create/Replace Datalog node. Otherwise you can't connect the resulting datalog refnum to any other file function, since it is an incomplete datatype.

Rolf Kalbermatter

[Larry_Stanos]

Thanks Rolf.  Encouraged by your success, I wrote a test program (attached) for determining whether there are any limitations to using Deny Access with datalog files.  Since I'm particularly interested in using my own user library vi's for general purpose (non-polymorphic) datalog file handling (e.g. datalog file open with retry and timeout), you'll see variant types as one option I tested when opening a datalog file.  In the end, I was successful with both fixed types and variant types provided that I typecast variant file refnums prior to write and read operations.  An alternative, using Variant to Data on variant datalog records was not 100% reliable when used in conjunction with Deny Access as the results in the attachment explains.  There may be additional pitfalls hinted at by the foreboding last line of the LV8 help topic for Deny Access.vi that states that you cannot deny access to a datalog file.  If anyone else does need to control write access for datalog vi's with a variant record input control, my recommendation would be to test the refnum typecasting method demonstrated in the attachment.

This whole thing started when code migrated from LabVIEW 7.1 to LabVIEW 8 wouldn't reliably read my LabVIEW 7.1 datalog files that had been created using typecast datalog file refnums.  (Cross reference thread http://forums.ni.com/ni/board/message?board.id=170&message.id=163292)  I now suspect that I may have to convert my databases in LV7.1 from typecast refnum-based to fixed data type-based datalog files, then perform the reverse conversion in LV8 to regain the use of my user library routines. 

Thanks again for your assistance!

Larry