Multiple users accsessing and copying the same file under linux?

[xavier30]

Dear users of the LAVA forum

I did some brief searching in this (and other) forums, but i couldn't quite find an answer to my problem:

I have a non reentrant and non template vi which is not developed nor maintained by me (which basically means i would prefer not to change any of the preferences or properties of this vi).

This VI is called by an application i created, where i copy the top level vi i want to call, and when the called vi is in memory, i delete the clone:

This way i can launch multiple instances of the VI without making it reentrant, or saving it as a template.

My problem is that this only works when i am the same user as the one who created the called vi. At once i switch to a different user, i don't have the write priveliges to this repository, so i can't do the copy.

To overcome this problem i tried to save the clone in /tmp, but there labview can't find the sub-vi's belonging to the clone, so if i use this technique, i would have to relink the hiearchy every time, or clone the whole hiearchy.

So my question is this:

Is it possible to change user for the catalogue where i'm copying the clone, just for this one operation, programatically, without being root, or do i have to find a way to relink the hiearchy of the clone?

(i guess i could specify the path of the sub-vi's of the clone in the "vi search path" and create a custom init file for this application by adding the -pref "path to init file" token in the startup script, but i was hoping there could be some other way to do this, since this variable as i understand can only be set at startup and not during runtime? which means i would have to restart the application every time a change in the structure of the called vi has changed?)

Just fishing for sollutions here any input would be helpful!

Cheers

X

[Adam Kemp]

If the problem is permissions then the solution is to modify the permissions. The easiest fix is to just make that directory world-writable:

$ chmod a+w dirName

You may also need to do the same for the VI itself, but I think if you copy a file then the new file has the ownership and permissions of the user doing the copy. I may be wrong about that.

The safer way of doing this would be to define which users can do this, put those users in a special group, change the group of that directory to your new group, and then make that directory writable by that group (but not by everyone else). You do the last steps like this:

$ chgrp newGroup dirName $ chmod g+x dirName

[xavier30]

QUOTE (Adam Kemp @ Aug 18 2008, 06:48 PM)

If the problem is permissions then the solution is to modify the permissions. The easiest fix is to just make that directory world-writable:

$ chmod a+w dirName

You may also need to do the same for the VI itself, but I think if you copy a file then the new file has the ownership and permissions of the user doing the copy. I may be wrong about that.

The safer way of doing this would be to define which users can do this, put those users in a special group, change the group of that directory to your new group, and then make that directory writable by that group (but not by everyone else). You do the last steps like this:

$ chgrp newGroup dirName$ chmod g+x dirName

Thanks for the input. I could change the permission of the folder containing the top level vi, but i was hoping to avoid this. I guess in the end this would be the easiest sollution.

I guess what i was fishing for was if there was a way to programatically re-link the VI's (something like a "mass compile light") if i chose to store them in /tmp.

X

[Adam Kemp]

Even if there was such a solution I would still recommend the permissions fix over that.

Ultimately I think the problem is that the VI isn't reentrant. You should at least make a request to whoever wrote the VI asking that it be made reentrant. With the new shared clone reentrancy feature in 8.5 there's not much of a downside to making commonly called VIs reentrant.

EDIT: Also, I thought that the only difference between a .vi and a .vit was the file extension (I could be wrong). In that case you could just rename the VI and do whatever you would normally do for a template VI. That's not a code change, so there's no maintenance issue.