Reading File Cache USB

[Hooovahh]

Okay I don't have tons of history with Real Time but I'm seeing some strangeness and I'm wondering if it is normal, and if there is a possible work around.

I have a PXI chassis running RT (the non-linux version).  I made a VI that all it does in a loop is read the u:\Config.ini file and show the text from the file.  When I first run the code I don't have the USB plugged in so it returns an error, and the text is empty.  I then plugin the USB drive and it shows the text in the file in this case I put the string "test".

Then I unplug the USB drive (the error comes back and text is empty as expected) and plug it into my PC, open the Config.ini in Notepad and change the file to contain "blah".  I save the file, close Notepad, and safely remove the drive.  Then I plug it back into the PXI chassis and after a few seconds returns the text "test".  I unplug it and plug it into another port and it still returns "test".  If I stop the VI with the drive plugged in, and start it again it still returns "test".  But if I stop the VI, unplug the USB, run the VI, then plug it back in, it reads "blah".

So what is going on here and how can I stop it from happening?  Why are files being cached in this way?  I could see a scenario where a user plugs in a drive with some settings on it into their computer, change some settings and plug it back in, without restarting the chassis.  In this case it would return the wrong information because it didn't read from the drive but instead read from the cached version.  Thanks.

Windows 7 x64 host (LabVIEW 2015 32 bit)

PXIe-1071 chassis, PXIe-8100 controller.

[RichieTheBard]

If you are not doing it already I would suggest you try using some error handling to try and close the reference to the file you created, once the USB device is disconnected, since that could be preserving a copy of the reference in memory as you suggested.

I'll try running this on a similar setup when possible, and see if it might be a possible bug with the way the file references are handle.  

[Hooovahh]

I just tested this code this morning and it exhibits the same behavior.  Attached is the code on the RT chassis.  If I plugin a drive that has a file on the root of the drive that is Config.ini this will show the file contents and there is no error.  Then if I unplug it, plug it into my Windows PC, change the file contents, save it, safely remove it, and then plug it back in the file contents are what was read the first time, with no error.  If I then stop my program, and restart it, the text read from the Config.ini is the new contents.

If this really is a bug and not just my misunderstanding I could see this being a big issue where you plugin a drive that has some text file and the program is meant to append newly read data to it, but when it goes and reads the file, it doesn't read all that is there and there is potential for data loss.

[RichieTheBard]

 I was able to workaround this with the following code. The idea is to prevent the USB drive from being disconnected during a period when it might be being read from, since I was thinking that this could be generated by the error occurring while the program is reading from the USB drive. I don’t know an specific reason why this would happen, but it does seem like it can be prevented by ensuring that data is not being read at the time you disconnect it.

[Hooovahh]

Nope, that didn't fix it.  

I added your VI to my project under the RT target and ran it.  It then came up with No file found.  I plugged my USB into my computer and made a text file with the name it was looking for with the text "abcd".  I then safely removed the drive and plugged it into the PXI chassis.  It then read the file and in Text showed "abcd".  

I then clicked Eject, and it said No drive connected.  So I unplugged it from the PXI and plugged it into my PC again.  I opened the text file and made it contain "1234" saved it and safely removed it.  I then plugged it back in the PXI chassis, waited several seconds, then clicked the Eject again so it would read the drive.  The text it read was "abcd".  If I hit stop and run it again, it still shows "abcd", but if I hit stop, unplug the USB, hit run, then plug the drive back in, it reads "1234".  During all of this I used the same USB port on the Windows host, and the same on the PXI chassis.

[RichieTheBard]

We’ve been looking into this and at the moment it seems as if this may be a bug with the Pharlap OS, since we have verified that this behavior has only occurred with this kind of RT systems, we are looking into this possibility.

We also noted that the size of the file that is stored in memory can affect the size of the file in the USB drive, if the operations functions that are used in the VI are not declared explicitly as “read only”, since we noted that the additional characters got cropped if this is not done.

We’re looking into the possibility of this being a bug, and a workaround for this behavior, that as I mentioned it only seems to occur with Pharlap OS, I’ll make sure to post about anything we find related to this issue.

[RichieTheBard]

Sorry for the time between my post here, we tried a few different things to see if we could find a workaround to this issue, however we could find a reliable way to get this working. After discussing this internally we decided to file a Corrective Action Request for this issue, as it definitevely seems like there's a problem with the way Pharlap handles this files.

The number for the CAR is 570143, and if it is corrected it would be notified in one of the future release notes of LV RT.