LabVIEW
why do I have to close a file refnum after doing a Write File and before a read file
Solved!
What's the exact name of the example? What is your LabVIEW version?
(In 2015, there is the example "Write to text file and read from text file.vi" and it has a case structure with 5 cases. Which case are you talking about.)
Can you show us the code of "when I try this..."? Thanks.
OK, I guess you are talking about case #1 in the example I just mentioned.
If you don't close the file, you need to set the file position to the beginning before reading, else it will read from the current file position, which is after the stuff you were just writing.
(Closing and re-opening will reset the position ot zero, of course.)
Ricardo90 wrote:
Why can´t you use Open File with Create/Open option with Read/Write access, write to the file and then read it (and close the reference only after doing the Read? I try to do this but I don´t get any data when I read from the file....
As far as this exact situation, it is because the file pointer is at the end of the file. So when you try to read, there is no more data to read. You could use the Set File Position function to set the file pointer back to the beginning of the file before reading.
A reason I can think of for the File Close is to make sure the file is actually written to the disk instead of just in the file buffer.
@crossrulz wrote:
A reason I can think of for the File Close is to make sure the file is actually written to the disk instead of just in the file buffer.
I don't think that's true. I am sure the file caching algoithms will avoid that (you could also insert a "flush file", but I am sure it is not needed here).
Setting the file position as follows works just fine.
Actually you are both right. Crossrulz didn't say that the close is necessary in order to read the data back, only that it makes sure that the data is written to disk as it does an implicit Flush File before closing.
Of course if you read back the data, that has just been written, without closing the file it will read back the right data even if it hasn't been commited to the physical file yet. If the driver decides to cache data it better is able to reference that cached data too instead of attempting to read in stale data from the disk. An OS which doesn't do so would be absolutely unusable.
@rolfk wrote:
Actually you are both right. Crossrulz didn't say that the close is necessary in order to read the data back, only that it makes sure that the data is written to disk as it does an implicit Flush File before closing.
Yes, of course. That's how I meant it. I was questioning the example, not Tim. 😄
I don't understand why the example offers only the "close...ref to path...re-open" detour, with the description to "do that when calling read and write in a loop". (see picture above) That seems somewhat convoluted and could be misleading. SImply resetting the file position before reading seems to be a much more direct approach, especially in a loop! 😄
When calling in a loop (which the example only describes, but does not actually show. See description above the red circle in the picture above), the file should be opened before the loop, kept open for the duration of the loop and across all read and write operations, and only be closed after the loop has completed. When just looking at the example description, the newbie might place all of the opening a closing inside the loop, doing much more work than necessary. The loop usage is important, and maybe the example should explicitly show that scenario too.
