Can I open a binary file twice, for simultaneous read and write?

[dhfx]

I have a situation where I am streaming binary data in via USB from a piece of custom gear, and I want to write the data to a binary file as it comes in. At the same time I want to be able to generate a monitor display of the data while the acquisition is in progress, by reading from the file (behind the write) . Can I simply open the same file twice, for writing and reading, using two separate file-open VIs? The writes will always append to the end of the file, and the read location may be random up to the current end of the file.

[PJS]

Why not just pass the open file reference rather than "re-open" it?

[dhfx]

I need to have effectively two location pointers into the file: one to where I'm writing (appending), and one to where I'm reading. I don't want to reposition the pointer in order to read, because this will (if I understand correctly) change the location for the writes, which will be asynchronous (probably interrupt-driven).

One question that occurs to me is: if the file is extended while it's open for reading, do I have to close and open it again in order to read the new data?

[Matthew_Kelton]

Why are you even trying to read form a file you are currently writing to?  You have the data already available when you do the write.  Use that data.  If your VIs are disconnected then use a queue, notifier, or user event  to send the data to the other VI.

[PJS]

Off the top of my head I do not know.  Never tried that.  I I do not believe you have to close and reopen.  It would take an experiment that I am sure you are just as capable as I am of trying.  As for the file position, you can use the primitive to set the file position for the writes to END OF FILE.  You indicated that your reads may take place from anywhere within the file. 
Are these to autonomous actions within the same process..  IE same EXE (either LabVIEW or your built one)?  You indicated that the read would always take place AFTER the write. Is there any chance of collision?  If you are going to put a mechanism in such that a collision is impossible, my recommendation would be to create a sub-VI with a write and read function.  Set the file position to end of file before every write, and set it where you want for the read.  Just a suggestion. 
It boils down to the speed of the reads and writes, and the size of the datafile.  I do not believe that opening dual references will cause a problem as long as you do not open it as locked.  Again, you can try it out.  It would not take long to do an experiment with a text file.  But as long as I am on the subject, how are you planning on enforcing Reads after writes?

[altenbach]

In the time it took to write this question, you probably could have made a simple demo VI and try for yourself. 🙂

Yes, you can open a file twice, and yes you can write to it and read from it from different locations. There is nothing special about all that. Attached is a very quick draft to illustrate my point (probably needs a few tweaks and error handling).

I also don't think you need to do anything special to keep things up to date. I don't think a "flush file" operation is needed.

Message Edited by altenbach on 09-27-2007 09:24 AM

[dhfx]

There could be a LOT of data, and I don't want to hold it all in memory; I have to write it to the file anyway for preservation. I already have the viewer portion working, reading from a (dummy data) file. The viewer will be used for analyzing the data offline after acquisition. I would also like to use it to monitor the acquisition process if possible. It seemed that the simplest way, programming-wise, was to read the file as it's being written.

[dhfx]

Thanks for all your responses. My last reply (out of sequence) was to Matthew K. To altenbach: I agree, I don't think a flush operation is needed, except after the final write. As soon as I get a chance I'm going to play with your example and do a few of my own.  - dhfx

[Matthew_Kelton]

It would only use a small amount of memeory over doing th reading, and that is just temporary until it is removed from the queue or a new notifier.