[Bug] Saving a Config (INI) File Should Not Replace Original File

[Jim Kring]

I think I found a bug in "<LabVIEW>\vi.lib\Utility\config.llb\Save Config File.vi" (the Configuration File VIs)...

When saving a config (INI) file, the original file is "replaced" (deleted and then a new file created in its place, as opposed to simply opening and flushing the contents of the original file).

The problem with this are as follows:

1) A user might have write permission on the file, but might not have permission to create new files. So, attempting to replace the file will cause a file permission error, even when the user has write permission on the file itself.

2) The new file might have different permissions than the original file. When the original file is deleted, all its permissions/ownership settings are lost. The replacement file will have default permissions based on the user creating the new replacement file.

Here are some screenshots of the buggy version and the fix for this issue:

And, here's the fixed VI:

Save Config File -- FIXED.vi

[Chris Bolin]

Here are some screenshots of the buggy version and the fix for this issue:

So moving from MacOS to Linux fixed the issue?

[Chris Bolin]

But in all seriousness, I completely understand how this affects users. It's good to note that this would happen in the basic, standard use case of just opening a opening a config file, writing a value, and closing, all with the public Config file functions in the palette. You've narrowed down the root problem in Save Config (a non-palette VI), but users would see this bug in Close Config (a palette VI).

[Jim Kring]

So moving from MacOS to Linux fixed the issue?

Hehe... no. It's just that the bug was seriously hampering me on Linux, so I fixed it there and overwrote the installed VI (which is generally a bad thing to do). Then, in order to get a screenshot of the original, buggy VI, I needed to go to a different LabVIEW installation and the one on my Mac was handy

But in all seriousness, I completely understand how this affects users. It's good to note that this would happen in the basic, standard use case of just opening a opening a config file, writing a value, and closing, all with the public Config file functions in the palette. You've narrowed down the root problem in Save Config (a non-palette VI), but users would see this bug in Close Config (a palette VI).

Yes, that's exactly right, Chris.

Thanks,

-Jim

[Ton Plomp]

Or is the bug the behaviour of the actual 'Replace' action?

I can see how the fix could be the default behaviour for 'Replace'! (or is it a big no-no in computer science)

Ton

[Jim Kring]

Or is the bug the behaviour of the actual 'Replace' action?

I can see how the fix could be the default behaviour for 'Replace'! (or is it a big no-no in computer science)

Ton

I'm not sure if I agree with changing the default behavior of "replace". I can see how this would change the behavior of some people's applications who already rely on the fact that "replace" also replaces all of the permissions/ownership settings of a file.

[sth]

Well it is good to keep a the old file until you sucessfully write a new file. In terms of say "hard links" to the file it is significantly different to create a new file and delete the old file.

The best way to do this in terms of safety and not messing things up, is to create a backup of the original file (if possible since you may not have write access to the directory) and then attempt to update the original file. If it all fails then put the old data back and abort out. This way if the OS aborts while the file is open you have the backup.

[Rolf Kalbermatter]

The best way to do this in terms of safety and not messing things up, is to create a backup of the original file (if possible since you may not have write access to the directory) and then attempt to update the original file. If it all fails then put the old data back and abort out. This way if the OS aborts while the file is open you have the backup.

Well usually you don't create backup files in the same directory anymore, just for the reason you mention of not having the according rights to the directory anymore. Instead you copy it to the temp directory, update the old file and if anything fails, attempt to move the backup back or on success delete the backup file.