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

[nathand]

The files are settings files (ini format, but not using the NI config file routines, so basically text) that are read at startup. The code in question opens each file, and looks for settings in it. If a specific setting isn't found then a default is loaded, so there's no reason to case out the file not existing at all. Using "Open or Create" followed by a read means that we don't get an error whether or not the file exists, and keeps the code simple. We open the file for reading because that's all we want to do, and we close the reference right after reading the file contents. Changing the mode to read/write solves the problem and doesn't cause other problems, so again the issue is inconsistency across platforms.

The fix is simple but finding the source of the problem was not. It manifested itself as an inability to save settings (because on the first run, it created empty read-only files, but all I could see was that they were created but empty, not that they were read-only). Once I finally found the spot where the file is written I could see error 8 insufficient permissions, but the help for set file permissions says permissions are ignored on PharLap which made it particularly confusing.

[nathand]

---

@Bob_Schor wrote:

Know anyone "inside NI" to whom to notify to get this "adjusted"?

---

That's why I posted here - I thought this was the recommended way to "file a bug report," at least for an issue that does not require immediate assistance.

[rolfk]

Personally I tend to side with the opinion that with read-only, the create option should be ignored. Alternatively the file should be created as an empty file, but not as read-only. The difference between the two is the returned error code. The first will create an fNotFound error on open, the second an fEOF on the first read, but not leave behind an empty read-only file, which is pretty useless.

Reporting bugs here is not really a report. There are people at NI who browse these forums and sometimes do create a bug report in their bug database, but it is by no means a guarantee. If you want a bug to go into their bug trucking system you have to formally report it through https://sine.ni.com/srm/app/getassistance

They keep moving this stuff and while it used to be right in the top of the support page in the past, it now is halfway down the support page that you get by going to Support page in the HUGE menu bar at the top of the NI site and then scrolling down three pages or so.

[Bob_Schor]

If you do report a Bug by filing a Service Request, be prepared for the response "That's not a Bug, that's a Feature" (which I've gotten more than once!).  However, you can then respond and "argue your point" -- I have prevailed once or twice ...

Bob Schor

[TyVo]

Hi All!

I just submitted a Corrective Action Request for this bug. CAR #710253. I came across this post while researching this error for a different customer.  I agree that VIs should exhibit consistent behavior across platforms so hopefully this kink will get worked out. Thanks for your input into this issue!

Best,

TyVo