[sldev] [SVC][VWR] Broken inventory and ways to break it

[Phoenix]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20081224/f2b8f268/PGP.pgp