MantisBT - opensim
View Issue Details
0008700opensim[GRID] Inventory Servicepublic2020-05-10 22:432020-05-11 04:37
Willy 
 
normalminoralways
newopen 
PC Intel Core I7 - Ram 16 GoWindows10
0.9.1.0 
 
Standalone (1 Region)
BulletSim
XEngine
Mono / Windows
4.0.1
Firestorm
0008700: IAR command - Script located in object's inventory
When we create an iar file by setting the permission --perm = CTM, we get after import the objects and the scripts with all the rights (in this case everything works correctly)

But if a script is in an object, when we open the inventory of this object after the import, we see that the name of the script is followed by the mention (no copy) (no modify)

Also, we cannot view and edit the script.

I tried to see in which database table is this type of script, located in the inventory of an object, but I did not succeed.

For a script placed in the inventory of an avatar, we can easily modify the rights by a simple update.

Currently I want to migrate my database from Mysql to Postgresql, because its size exceeds four gigabytes and Mysql no longer works correctly.
For this migration, I use IAR command, which allows me to filter my data and take only the objects that are useful to me.

But I am blocked by these scripts placed in the objects, which are no longer readable and modifiable after import.
Provisionally, is there a workaround using sql queries ?
1 - Create a simple LSL script in the inventory of an object (a cube)

2 - Launch an IAR command to save this cube located in the avatar's inventory.
    [save iar --perm=CTM bob dino Objects/cube mypassword C:\cube.iar]

3 - Launch an IAR command to load this IAR in another database
    [load iar --merge bob dino Objects mypassword C:\cube.iar]

4 - Rezz the cube, which was imported by IAR command, an try to open the LSL script located in its inventory:
    This script is no readable and no modifiable


This problem is reproducible on the previous version of OpenSim (0.8.2.1)
No tags attached.
Issue History
2020-05-10 22:43WillyNew Issue
2020-05-11 03:37tampaNote Added: 0036470
2020-05-11 04:37WillyNote Added: 0036472
2020-05-11 04:55WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9026
2020-05-11 04:56WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9027
2020-05-11 05:00WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9028
2020-05-11 05:01WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9029
2020-05-11 05:02WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9030
2020-05-11 05:10WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9031
2020-05-11 08:08WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9032
2020-05-11 08:08WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9033
2020-05-11 08:09WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9034
2020-05-11 08:42WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9035
2020-05-11 08:43WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9036
2020-05-11 12:00WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9037
2020-05-11 12:09WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9038
2020-05-15 08:27WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9039
2020-05-25 08:25WillyNote Edited: 0036472bug_revision_view_page.php?bugnote_id=36472#r9058

Notes
(0036470)
tampa   
2020-05-11 03:37   
Okay seems to not obey the setting rather than modify it from what I can tell there seems to be no code to look into the object, just the asset, which has no code to handle the flag.

Beside that though, "Currently I want to migrate my database from Mysql to Postgresql, because its size exceeds four gigabytes and Mysql no longer works correctly." What? Sorry but that shouldn't be happening at all, mysql is more than capable of handling very large tables just fine. If you encounter issues you need to tune your configuration.
(0036472)
Willy   
2020-05-11 04:37   
(edited on: 2020-05-25 08:25)
It seems that the avatar UUID is in the IAR file, which is not normal.
There are therefore three possibilities to solve this problem.

-> delete this UUID in the IAR file.
-> be able to mention the avatar's UUID in the IAR command.
-> choose the UUID of an avatar when creating the database or when creating a new avatar.

Personally, I think this last option would is the most interesting to temporarily work around this problem.
If the user who needs to use the iar has not yet been created, is to choose the avatar uuid, instead of take the uuid offered by opensim.
The CREATE USER command also allows this option, if the database is already created.

[Remarks]
I have not tested every case.
For creating and loading an IAR in the same version 9.1 of opensim, the --perm = CTM option may be fully functional.
But for the creation and loading of an IAR from a version 8.2 of opensim to a version 9.1, the --perm = CTM option is valid under certain conditions.
Rather than modifying the code, you should perhaps comment on this option perm = CTM
What is certain is that choosing the same avatar name with the same uuid solves this problem.
Maybe, another way to solve this problem would be for the user to modify the rights on the scripts, with an update command, in the PRIMITEMS table, before the objects return to the inventory.
If the objects are already in the inventory, it is too late because the scripts in the inventory of the object, are coded in binary in the column DATA of the table ASSETS.
We can also try to manually modify the rights on the scripts, in the object inventory (but it is often burdensome!)