On 2008-12-24, at 4:21 , Robin Cornelius wrote:
1. Buy the contents of an object and pass back a UUID zero as the target
folder.

This generates a usable toplevel folder next to  My Inventory and
Library. This can be undone by moving the folder back to the correct
parent. This is actually quite useful.

In this state, the viewer should operate normally but many processes on the server assume a single 'root' folder. Inventory may break in strange and interesting ways that are hard for me to predict without some research.


2. Copy an inventory folder and set itself as its parent

This really confuses the viewer and the viewer shows a new complete
inventory root inside the new folder (All Texture/Trash/Lost and
Found/Scripts etc folders present in new folder as well). Seems to break
many inventory operations with the viewer

I'm surprised the viewer does not lock up building the internal indexes. That's good news. I'm not at all surprised that many operations break.


3. Create a folder with an ID the same as the inventory root

Now how this happened was anybody guess, it was either by trying to
remove a condition #2 by moving the folder back to the correct parent,
or via some unknown mechanism. In any case this can happen and i have
seen it and have an account in this state now, ps not mine, i didn't do
it ;-)

This should not be possible at all. Internally, inventory is uniquely identified as (agent_id, folder_id) for folders and (agent_id, item_id) for items. I would expect the duplicates to be suppressed and all evidence of their existence to disappear on relog.

Please file service bugs and point me at them so I can take a look. Since all inventory use agent_id as part of their unique identification, it's not terribly important to generate the id on the server (thus requiring a major protocol overhaul). However, the back- end should loudly reject data inconsistencies such as these.

Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges

Reply via email to