Determine if a TDMS file is already open

[josborne]

In my system, I'd like to know if a TDMS file is currently open.  Eg. if another VI or executable has opened a TDMS file reference to it.

TDMS files are unique in that it is perfectly acceptable to have 2 active file references open at the same time.  Even from different executables.  Because of this uniqueness, this technique does not work:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019YXfSAM&l=en-US  

Any tips?

I suppose I could try some technique of writing a keepalive timestamp (e.g. "most recent write time") but that seems clunky and would adverserly effect performance.  Plus the data is buffered only flushed to disk occasionally.  Would be nice if there was a hidden property somewhere that I could access.  

[Hooovahh]

Why do you need to know if the TDMS file is already open?  I might have a log open as read-only in several places, knowing that those references are just for reading, and I often close the reference to it after I am done reading.  But if I left it open and forgot to close, then I don't see how that should mean another reference can't be opened.

If you are writing to a file from two places at once things might get more hairy.  But if both are writing to separate channels, or separate groups then I think the TDMS driver will handle everything just fine.

If you do want to do a semi-lock out process, then you could try setting the file as read-only on the file system.  Then make it not read-only for updating, then setting it back.  Another option might be to create a new temporary file, that gets merged back into that main file when you are done.  TDMS files can be appended to very easily. 

[josborne]

>>Why do you need to know if the TDMS file is already open?  

I have a distributed application with multiple executables that are writing to TDMS files on a central drive.  And then we have (potentially) multiple executables that are browsing that central drive.  It would be good for the browsers to know which files are actively being written... it is good from a systems and file management perspective.     

[Hooovahh]

Well there is a delegation of duties that could be used here where each application is only responsible for writing to its own files.  And then there could be a single central program that knows of all these child like applications and can bring them together.

Another option might be to just open file references to TDMS files as if they were binary files, which seems like it would lock the file since at that point it is just accessing it with the normal File IO stuff.  Then release those references when you are done, but never actually write to it using this.