A File Reference and its evolving life!

[CoastalMaineBird]

Attached is the test file I used.  I am posting this to NI TechSupport as an issue.  It seems to be a misbehavior, regardless of whether you think the path reported should be NAME 1, or NAME 2.

You're right - I was thinking strictly in LV terms - if you want to operate with minimal software installation on the client side, then disregard what I was saying.

[CoastalMaineBird]

I reported what I saw to Tech Support, and they asked me to make a JING of it.

During the making of that, I discovered something:

In the first JING, it is exactly as I described it - the file exists as NAME 2, but it is empty.

In the second JING, something is different:

I OPENED the file via FTP, after writing the first part, and the first text is 
there AND IT STAYS THERE throughout the renaming.

The file exists under NAME 2, but now it contains the first text.

IOW, the act of OPENING the file via FTP, after writing the first text, changes 
the behavior!

[QFang]

TLDR;

MAYBE what you are seeing has to do with caching/ftp browser.

That is strange... I saw a similarily unexplainable thing once, which could be tracked down to how the FTP software (in my old case, Windows (File) Explorer) and how it implements caching.

We now exclusively use cuteFTP with the global settings set to 'never cache' and 'binary' instead of auto transfer.

I'm not sure how robust Chrome(?) is as an ftp solution, if thats what you used, but be aware that you can get VERY strange results in certain cases.

In my case, using Windows Explorer, I sometimes ended up with strange mixes between old file content and new file content, to the point where I would have the cRIO simply write "HELLO????" to a text file, but when I refreshed (in file explorer) and re-opened the file, it would have MB's of old log data..  The ftp size would report one thing, the number of bytes in the file I opened would be a different size, the text would be from old and new logs mashed together, it was very bizarre and turned out to have nothing to do with the cRIO or its app'.

This seemed to be more prone to happening when the file name(s) were constant, but the contents would change very frequently.

[johnsold]

I have not worked with the cRIO, but on some OSes file writes merely tell the system that this data is to be written to the file. The actual write may not occur until the file is closed or some magic number of bytes have been cached.  The LV Config file VIS work that way.  Could something like this be related to what you are seeing?

Lynn

[QFang]

Hi Lynn,

In the case of my test code (post 7 in this thread) it cannot be the issue, because I call the flush function after each write. 

You are correct that cashing etc. could mean data is not written when you expect it, but flushing (or closing) properly forces all cached/non-written data to the file.