A File Reference and its evolving life!

[CoastalMaineBird]

I'm not quite sure if you are facing an actual problem, or just a theoretical one.

If you have actual users logging in and diddling about, and if you can't keep them out via password or something, then consider a backup plan: write TWO files, one in the HELLO FOLKS HERE'S YOUR DATA folder, and another copy of the same file in the "DO NOT ENTER" folder or "X3AA56152" folder or "FBI-NSA TRACKING DATA" folder or something.

Every morning at 3:00 AM copy from the backup folder to the public one and overwrite the public one.

Just a thought.

[QFang]

It's sort of both, but at this point it is mainly a theoretical one, and also a question of awareness (since I think the behavior of the close function was somewhat unexpeceted) and if this is a feature or a bug.

For now the issue was fixed by a quick e-mail, but it prompted an investigation on our end on what we can do to make the system 'even more safe and robust'.

The main issue with your suggestion is mainly one of resources (CPU, ram), and it also only moves the issue, it doesn't 'fix it' since it still relies on training of personell with access.  Password isn't usefull either, since (these devices) only supports one 'user', and the customer needs that password to do legit FTP copy transactions. (More specifically, you can configure a bunch of users for a cRIO-9014, however, ftp access requires the admin password, so any restricted user you create via max/web interface is moot as you need to provide them the admin password anyway).

We're investigating hardware migration to e.g. NI LinuxRT targets (better user management), as well as locking the customer out entierely and having the cRIO 'push' files to a an external webDAV server (WebDAV API currently has an internal memory leak, so its stuck in R&D deployments only for now) or FTP server (most customers can't use that solution since most don't allow unencrypted ftp traffic on their plant networks).  In the mid to long term, we picture completing the migration to LinuxRT AND being able to require that customer takes delivery of files by providing (or letting us provide) a server setup for WebDAV, allowing us to completely lock down the cRIO's.

[CoastalMaineBird]

OK, I don't know much about cRIO, as I work in PXI, but another thought is to serve the files yourself.  TCP file transfer is not difficult, and you can put whatever restrictions you want on it.   It does use up code space though.

Just a thought.

Have you reported this to NI as a bug?  It might have a chance of being addressed.

[QFang]

Yes, we have considered our 'own' tcp transfer mechanism, I'm very familiar with TCP level communications, but the main reason to stay away is that it would require us to provide, test and maintain server side software (and possibly hardware) as opposed to just having their IT setup and configure a webDAV server on a server machine they already host on the net.. This is both for them and for us, as it does not introduce new equipment for them to consider/maintain vs threat vectors, configurations etc., and it leaves them with total control of patching, updates etc.. To us it is ideal because its on them if the server goes down or is not working. 😛

[rolfk]

---

@QFang wrote:

As far as the 'resources' or overhead to update the file-refnum with the new information, this would not be needed to be done in a polling fashion, simply, when the file-close function is called, as part of that call it updates its internal register from the pointer data, so this should be a low overhead operation I would think?  If that is a true concern, a boolean input defaulting to not updating or a separate 'advanced close' could be created?

---

You would think that is trivial to do. But check out this page from the source about how to do it in Windows. Opening a file mapping object just to retrieve the actual file name of a file handle? Ouch, talk about using a hammer to drive in a screw!

And here the more general case of a file descriptor (C runtime library and Posix API on *nix sytems).

Basically there exists no portable and reliable way to do what you want to do. Of course deep down in every OS, there are functions that can do that (Windows most likely in ntdll.dll) but those APIs are usually considered private and can therefore change between versions as well as they are inherently very platform specific.

While a LabVIEW file refnum is pretty limited in its underlaying object definition (it refers to an actual file object in the filesystem which of course has a name) that is absolutely not true for the underlaying object type (Windows handle or Posix file descriptor, or more obscure types like under VxWorks which uses a Posix like interface but is anything but Posix compliant). So LabVIEW tacks the file name to the Refnum on opening and simply relies on the fact that nobody is going to change a file under its feet. Most likely they had to do that to support the old LabVIEW for Mac Classic interface which was generally very closely mapped to the MacOS API. And there it seems to have been common to return the file name when closing a file reference. But then a MacOS file descriptor was not an opaque pointer but a completely defined structure with many individual fields in there (something that bit the Mac developers many times later on as they had to create ever new APIs to support a new feature, to not cause existing applications to crash. Eventually they removed quite a bit of that cruft when going to the Carbon API and got more or less completely rid of it with Cocoa, but that was a very painful process for any application developer.)

[CoastalMaineBird]

I didn't mean have your own server hardware, I meant serve it from the cRIO itself.  

As I said, I don't know much about cRIO, but PXI would be able to do that with ease.

But you've thought about it more than me, so I'll shut up now...

😉

[QFang]

Oh, I see.  Yes, we (can) do that for e.g. Modbus, and its simple enough to enable the cRIO to act as a webDAV server, the issue is then that the customer/client will be expected to go get files themselves, which which means all sorts of issues could happen. For example, they (incorrectly) download then remove a file while the cRIO app was in the process of updating that file. etc.  Its best (in my opinion) to let the cRIO application itself determine when it is safe to attempt a file-transfer (e.g. after a file update or when a log-file is complete and will no longer be updated) and when it is safe to remove/delete the (local) file (e.g. after successfull transfer to external device, remove the local copy, or 'remove oldest local copy that has been successfully transferred' or similar schemes).  This also prevents the external client from having to needlessly poll to see if there are updated data available.  But the roads to Rome are many, and just because they go in oposite directions doesn't mean they aren't both valid paths to take. 😉   

Thanks for all your inputs.  Still not sure if I should bother reporting this as a possible bug or not..  Is there a concensus amongst people (still) reading here?  Should I or should I not?

[QFang]

RolfK,  That was a greatly informative post/resources.. Thanks for educating me on the hidden complexities! 🙂

I agree, I don't think this is likely to be 'resolved' or changed.. perhaps its just important to keep in the back of ones mind if you are going for the most rugged application possible where you try to account for unaccountable events such as external file-renames.

[CoastalMaineBird]

Its best (in my opinion) to let the cRIO application itself determine when it is safe to attempt a file-transfer

That's what I meant, if I didn't explain it well.  Forget the standard WebDAV stuff, Just open a listener in your cRIO code, and respond when you can.

You can even respond "Go away, I'm busy!" whenever it's appropriate.

But, like I said, I'll shut up now... 😉

I think I will report the misbehavior of my PharLap box to Tech Support.  I would suggest you report your case as well.

[QFang]

... but I must be missing something, because that means the client (customer) making the request would need to run the LV RTE and a custom application that know what requests and what commands to use to get the data.  Hence, if we instead request the customer has a webDAV server (which comes with IIS for free if they run Windows or Windows Server machines, and I'm sure Linux servers have WebDAV servers as well), thus adding no new software on their end, and the controller won't have to handle (yet another) incoming stream of commands, instead just pushing files out.   Maybe we're just talking past each other! 🙂