LabVIEW
File permission issues when sharing project
The original problem is likely caused by the fact that LabVIEW, when saving back files, usually does in fact a shadow save and only after that save was successful, will it replace the original with the shadow copy. This does involve CREATING the shadow copy first and then MOVING it to the original location. Depending on how your users temporary directory is configured that COULD certainly involve a permission change on the resulting file, as LabVIEW uses the temporary directory for such shadow copies and files created in there will automatically inherit the permissions of the directory in which they are created, which may not be what your target directory uses. LabVIEW does not really have any support in its file functions to actively set any other permission than the read/write flag on Windows. Everything else is a result of inherent OS rules that just happen to give a LabVIEW created file its permissions.
This used to be an almost perfect method to avoid the problem of corrupting a file when something went wrong during the writing of a file. Obviously it does not cater to the case where each user has his own private temporary directory but multiple users on the same machine want to work on the same files in a common directory. In old days there was one global temporary directory that all users accessed but more stringent security requirements found this to be another possibility of leaking private credentials that may happen to end up in temporary files, or allow rogue processes to do denial of service attacks by blocking other processes from creating specific files such as lock files in there.
It was only with Windows 7 or so when Microsoft introduced transacted file operation APIs. That would be the correct way to do this nowadays but there are several reason why LabVIEW doesn't use this API:
- Much of the code for these low level managers was written 30 years ago and only adapted when needed by real problems
- LabVIEW works currently still on three different platforms (Windows, Mac OS X, Linux) and has worked on many more in the past (Sun Solaris, HP Unix, Mac Classic, Windows 3.1, Pharlap ETS, VxWorks) and changing the code in such a low level component that interfaces directly to VERY different APIs on each of these platforms is a difficult task.
And yes I do echo the recommendation to use version control. It's main advantage is not just multiuser support but to give a consistent history of the work on a project. Even if you are lazy with regular commits, which is of course your own choice, you still get some sort of history and a possibility to look back in time. The excuse that merging of LabVIEW VIs is not easy, is NOT a valid excuse not to use version control. Merging of files is just one possible aspect of version control and with a setup where multiple people all work on the same directory you don't even have the possibility to compare versions, lets alone merge them, so it is clearly a strawman argument.
And yes there is actually a solution for the temporary file permission problem here:
LabVIEW allows to set the directory which is considered the temporary directory in its options dialog. So create a separate Temp directory in your project folder with the correct permissions and reconfigure in the LabVIEW Options the temporary path. It should be of course clear that this is only a crude workaround. The proper solution is to use version control.
@Bob_Schor wrote:
OK, since I seem to be the one who brought up VCS (and, like @billko, I use Tortoise SVN), I have a few more comments:
- I've been using Tortoise SVN for about 15 years. It was a Game-Changer.
- Fabiola de la Cueva (a.k.a. "Fab") gave a talk at NIWeek about 5-6 years ago that I think you can find on the Web (sorry, I don't remember the title) that had a section "Get Yourself a Time Machine" which was all about the importance of VCS for LabVIEW Developers, including "single" developers (which seems to largely fit @billko and me).
- I only learned about changing the Environment Option (open LabVIEW, Tools, Options, Environment) to "Separate compiled code from new files". If you do this and then edit a pre-existing Project, it will have "old files" that probably don't have all its VIs "marked". Here's how to do this:
- Open the Project.
- Right-click the top ("Project: <Project name>") line and choose "Properties".
- Put a check in "Separate compiled code from new project items" (if not already checked) and click "Mark Existing Items". You can scroll the list and see if any are "unmarked", or just click "Mark Selected Items" (it's pretty quick to let it mark everything).
- Click "Close", all done.
- Before I ever learned about SVN (and, if memory serves, before I started using LabVIEW Project -- I was working with LabVIEW 7.0), I ran into the question "How does the code I'm trying to maintain differ from the same code as modified and running on another PC in the lab. I had my code, organized in a set of folders, and the "related" code, also organized in similar folders. Both were "derivatives" of a "parent" code base (I forget how we distinguished "Versions" in those days, probably by calling it "A-Lab 1.01", "H-Lab 2.1", etc.), with most of the VIs having identical names (but not necessarily having identical "contents"). At this point, there were hundreds of LabVIEW files, both VIs and TypeDefs.
- How do you deal with doing compares when you have more than a dozen VIs to pair-wise compare?
- I solved this by writing a (recursive) routine that parses the two Folder Trees and identifies VIs and TypeDefs that are present in both Trees, unique to Tree1, and unique to Tree2. Now I only need to use LVCompare to parse the identically-named VIs and TypeDefs present in both Trees.
- How do you deal with "version" comparisons with you have two VIs with the same name that you want to compare? LVCompare (at that time, and possibly still does, today) required both VIs to be in memory, and thus they need different names. When I first started doing Compares "by hand", I'd rename one VI (I usually added an "x" to the end of the VI name, e.g. "My VI.vi" and "My VIx.vi"). Well, it is easy enough to do a programmatic File rename (and un-rename) when you are done.
- One important lesson I learned from doing a few "huge" compares was the importance of doing regular Commits and documenting the changes in the Commit log (so you keep the number of changes to a manageable number, and can better "guess" where you "introduced the bug" in your code ...). You still need to look at all of the Comparisons and decide "where did I introduce the bug" (in my case, it is often a Wire I failed to reconnect ...).
- Another thing most "senior" LabVIEW Developers know (and I'm trying to practice more regularly, though working from home without the appropriate hardware makes it tougher) is to code a little, test a lot, then (and only then, something I haven't truly mastered) code some more ...
Bob Schor
I tend to commit after every significant change, especially if I am going down a potential rabbit hole.
