Bug: PharLap 13.1 opening/creating a new file for read causes the file to be read-only

[nathand]

An odd bug that I just ran across, specific to PharLap systems (we're running 13.1, LabVIEW 2015, on a PXI controller). The code below creates an empty read-only file if the file does not already exist. Attempts to write to the newly-created file result in Error 8 bad file permissions. Rebooting the system doesn't help, and programmatically deleting the file also results in Error 8, although it can be deleted over FTP. The same code works fine on Windows and VxWorks, so it's specific to PharLap. The file is being created "read-only" rather than read-only applying only to that particularly file refnum (between the Open and Close file references).

[Bob_Schor]

I'm confused.  You create a Read-Only file, then get Error 8 when you try to write to it.  It makes sense to me that trying to write to a read-only file might generate a "You do not have the correct permissions for the file" error.

What am I missing?

Bob Schor

[nathand]

Opening a file for reading only should not create a read-only file, or at least this behavior should be consistent across platforms, and on Windows and Linux this code doesn't create a read-only file.

If the file already exists and it's opened read-only, then it simply limits access through that file refnum to reading, but if you close the refnum and re-open the file for writing, then you're allowed to write to it without an error. However, here, if the file does not exist, a new file is created read-only and it's not possible to write to it, even after closing and re-opening the reference for writing. There shouldn't be inconsistency between how this is handled for a new file versus an existing one.

[Bob_Schor]

Aha, now I (better) understand what you are saying and trying to do.  I had written two or three paragraphs explaining the flaws in your logic, and was backing it up with some tiny LabVIEW examples, when I finally "got it" -- you are absolutely correct!

What convinced me was three 3-function routines, all starting with Create, a non-existent FileName, and Read-Only.  With Write/Close, you get the expected Error 8 (though you are also "reading past the EOF").  With Read/Close, you get no error, and a R/W file.  And if you leave out the Write (so it is Create/Close), you get no error and a R/W file.  So Open/Create should ignore the R/O flag in this instance.

However, if the file doesn't exist, why read it in the first place?  Also, does it make sense (in this special instance) to Create an empty File?  If the answer to both questions are "Yes", rather than trying to convince NI (who probably have a "good reason" for this behavior), just do your own tests (perhaps wrapping it up in a sub-VI with a appropriate "Fix for NI O/C Bug" label).

Nothing like playing with code to "see the light" ...

Bob Schor

[nathand]

---

@Bob_Schor wrote:

However, if the file doesn't exist, why read it in the first place?  Also, does it make sense (in this special instance) to Create an empty File?  If the answer to both questions are "Yes", rather than trying to convince NI (who probably have a "good reason" for this behavior), just do your own tests (perhaps wrapping it up in a sub-VI with a appropriate "Fix for NI O/C Bug" label).

---

These questions are beside the point. Code that was working properly on two different platforms unexpectedly runs differently on a third. We expect LabVIEW to behave the same way across all platforms (that's one of its selling points), and in this case it doesn't. The difference isn't documented, so I call it a bug.

I don't need suggestions on how to work around it - I've already done that. Are you suggesting I shouldn't report a bug simply because I can easily work around it? What if someone else encounters the same problem? Should they have to debug it on their own, too?

[billko]

---

@nathand wrote:

---

@Bob_Schor wrote:

However, if the file doesn't exist, why read it in the first place?  Also, does it make sense (in this special instance) to Create an empty File?  If the answer to both questions are "Yes", rather than trying to convince NI (who probably have a "good reason" for this behavior), just do your own tests (perhaps wrapping it up in a sub-VI with a appropriate "Fix for NI O/C Bug" label).

---

These questions are beside the point. Code that was working properly on two different platforms unexpectedly runs differently on a third. We expect LabVIEW to behave the same way across all platforms (that's one of its selling points), and in this case it doesn't. The difference isn't documented, so I call it a bug.

I don't need suggestions on how to work around it - I've already done that. Are you suggesting I shouldn't report a bug simply because I can easily work around it? What if someone else encounters the same problem? Should they have to debug it on their own, too?

---

I think Bob was so involved with the explanation that he forgot what the original intent of the topic was.  😉

[nathand]

I think Bob was so involved with the explanation that he forgot what the original intent of the topic was.  😉

---

Sorry, I did respond a bit too harshly - my frustration in finding this spilled over. I had code that worked fine in all my tests, then I moved it to the PharLap real-time system and suddenly it didn't work any more. This wasn't helped by an overly-complicated framework designed by consultants before I arrived that made it very hard to find the point where the file was actually written and didn't propagate the error up to somewhere I could see it.

[billko]

---

@nathand wrote:

I think Bob was so involved with the explanation that he forgot what the original intent of the topic was.  😉

---

Sorry, I did respond a bit too harshly - my frustration in finding this spilled over. I had code that worked fine in all my tests, then I moved it to the PharLap real-time system and suddenly it didn't work any more. This wasn't helped by an overly-complicated framework designed by consultants before I arrived that made it very hard to find the point where the file was actually written and didn't propagate the error up to somewhere I could see it.

---

Do I ever understand where you are coming from.  I'm sure you've been around long enough to see me go nuclear.  By comparison, your "outburst" wasn't even a firecracker.  😉

[Bob_Schor]

My apologies.  What is a "trivial inconsistency" to one person can be a "pain in the a**" to the one who is bitten by the bug!  Know anyone "inside NI" to whom to notify to get this "adjusted"?

BS

[natasftw]

---

@nathand wrote:

We expect LabVIEW to behave the same way across all platforms (that's one of its selling points), and in this case it doesn't. The difference isn't documented, so I call it a bug.

---

I'm curious what reply you'd get.  I'd agree there's a bug when it doesn't behave the same across platforms.  But, that does leave you with two potential options:

1) The behavior on Pharlaps is expected.
2) The behavior elsewhere is expected.

I'm honestly not sure how I'd expect the code to run in the case where a file doesn't exist.  It's a rather strange thing to open a read-only reference to a file that doesn't exist.  I'd lean more towards throwing an error if you choose read-only when a file doesn't exist and ignore the option to create the file. 

I don't know enough about your code to really understand.  I'm guessing you open this reference in one place and open a reference elsewhere to write and pass those references to different places depending on what access you want to allow.  Is that correct?  If not, what do you get from creating the file?