LabVIEW 2009, sp1, deletes file rather than replace if owner is different

[Bryan]

We are using LabVIEW 2009, sp1, on Slackware 13.0.  Several users are using the same VI which reads and writes a configuration file as well as a short text file to track usage.  If a user runs the VI and the files were created by a different user and then writes either of the common files, it will delete the old file but not write a new version.   Both files are saved with both group and user permissions as "rw-" and all the users belong to the same group.  The open/replace/create vi complains about a file permission problem, apparently after it has already deleted the existing file.

Has anyone seen a similar behavior or do you know of a solution to this?

Thanks.

[AdamKemp]

We need a bit more information.

1. Which primitive gives the error?

2. What is the error?

3. What are the permissions of the directory the file is in?

4. Are you using just a single primitive to replace the file or a sequence of primitives (delete, then create, for instance)?

5. Was the file actually deleted or is it just empty?

Sometimes it's helpful to try to replicate the sequence of steps you're taking in a shell script or just from the command line to see if you get the same behavior. That can often make it more obvious what the problem is. Usually it's just a matter of understanding all the permissions issues involved. For instance, remember that to create or remove a file you need permissions on the directory, not the file.

Of course it's also possible that it's a bug, so I'd like you to answer the above questions so that we can try to reproduce the issue here.

[Bryan]

Adam,

Thanks for the quick response.

The vi that gets the error is "Open/Create/Replace File".  In one case it is called by "NI_LVConfig.lvlib:Save Config File.vi" which was called by "NI_LVConfig.lvlib:Close Config Data.vi" and in the other case it is called by "Write to Spreadsheet File (String).vi".  Both get error 8: "File Permission error.  You do not have the correct permissions for the file."

The permission string on the directory is drwxrwxr-x with the group the same as all the users.  The file itself is -rw-rw-r--.

The curious part is that the file is actually deleted.  It usually requires the same (or more) access to delete the file than it does to update it.  I have tried modifying the file using an inplace editor from the shell.  I can edit the file and it saves the changed contents with the original owner (which is not the same as the user that is editing the file).

The description of Open/Create/Replace says that replace is done by just opening the file and setting the length to zero, which would seem to be roughly equivalent to what I do with the editor.

Hopefully this may shed some light on what is happening.

[AdamKemp]

I think the error is happening because we try to set the permissions on the file. Since you don't own that file, you can't set the permissions. Try deleting the file before saving the new one.

Things often get a little weird when you have multiple users all touching the same files. Ownership and permissions issues get complicated. It's usually best to avoid that if possible. Still, I think this is a bug, and I will file a bug report so we can try to avoid the error in the future.

[Bryan]

Deleting the file before updating it seems to cure the problem.  It is interesting that I can delete the file but the replace or create selection can't set the position of the file to the beginning and overwrite the file.

In any case, the problem is solved for now.  Thanks for your help.

[AdamKemp]

Overwriting the file isn't the problem. We can overwrite the contents as long as we have write permission. The problem is that we are trying to change the permissions themselves with a call to chmod, and that requires that you are the owner (or root). That's where the permissions error comes from.

Deleting the file only requires write access to the directory, and it ensures that the create file actually creates the file as the current user rather than trying to modify an existing one from another user.

I filed a bug report, though, so maybe in the future we can improve this behavior. Thanks for reporting it.