Vote and watch, thanks for putting it up for me.

EDIT: And I'm changing the title a bit. The crashes usually don't happen on detach, they happen if the person tries to touch them in inventory.

I filled in my environment info, but it doesn't really matter, I have friends using old and official viewers that report the same results. And yes, the objects themselves are unaffected by becoming parentless, their scripts still function properly. It's trying to left or right-click them in inventory that causes problems.

Edit: And by 'disappear', I mean from inventory, not from my avvy.

EDIT: About ten minutes after this comment, I successfully reproduced with this script (follow commented instructions):

//How to use:
//1. Make this script No-Copy/No-Mod/Yes-Trans
//2. Make the object containing it Yes-Mod/Yes-Copy/No-Trans
//3. Give the object to another account, so that it becomes no-trans.
//4. Rez and allow it to attach. When it detaches automatically, try clicking it in inventory. It will disappear to below the Library.

default
{
    on_rez(integer ss){llRequestPermissions(llGetOwner(),PERMISSION_ATTACH);}
    run_time_permissions(integer perm){if(perm&PERMISSION_ATTACH){llAttachToAvatar(ATTACH_RHAND);llSleep(10);llDetachFromAvatar();}}
}

It requires an alt for step 3, or a friend. You won't be able to repro yourself (because you have it full-perms as creator), but anyone you give it to should see what I'm talking about.

Tested it then with Crystals Script above, a no mod,no copy cube and send it to an Alt, and the same happend again. This make content lost permanently in my case.

Official Second Life Viewer 1.22.11 . Happend on three different regions.

Edit: ok, saw the related entrys now and go vote on them, too.

VWR_6110

llAttachToAvatar and wearing from the ground appear to have the same root problem.

The bug can be prevented when you got the item into inventory and while it appears, you move it into another folder before having it detached by script.

Time seems to be a factor as well, so adding a bunch of complex mono scripts would make this bug happen more likely.

derez is something that happend on detaching and taking

when taking objects, they are moved back to the folder they were rezzed from
should this feature happen during derez, the shared code of take and detach, it may try to move the item into a non-existing folder

if derez exists in that form, I'd point out, that the sim's idea of folder_id for the root prim of a linkset should be changed during attach to have the folder_id of the Object folder, so derez would simply move it to the Object folder, having no effects then

uhm, alternatively, it could be just because the item is no modify, that it's moved to NULL_KEY folder

I'm using the official Second Life 1.22.11 (113941) Viewer

It's spooky to see an Object appear in an "impossible and inaccessible" location like that...

I'm using the official Second Life 1.22.11 (113941) Viewer

It's spooky to see an Object appear in an "impossible and inaccessible" location like that..."
I have had this happen as well and whats even more freaky when you try to drag the item to your trash the black circle with a dash tho it icon comes up and the viewer crashes.

The avatar who reproduces this is not the creator of the item and item is yes-copy/no-transfer/no-modify.
(if it matters: the creator of the item had it in the MyInventory->Objects-folder before giving it to the test person.
Test person now:
1. rezzes the item inworld (on the ground)
2. this item asks for permission_attach
3. when permission is granted it attaches,
the item appears in the MyInventory->Objects, so far correct.
4. if test person now detaches the item, it moves out of the Objects-folder to below the Library-folder.

This out-of-all-folders-item cause these problems:

• The attempt to drag'n'drop the item into any folder/trash results in a crash.
• After a relog the item has disappeared from inventory. (even if it's still worn it is not visible in inventory or the "Attach to..."-menu.

One other thing of note that keeps coming up from my customers is that existing items can lose their place in the inventory. Try these steps to compare:

1. Create a new object and name it "Test"
2. Create a new folder in your inventory in the "My Inventory" folder and name it "Test" as well.
3. Take the Test Object into your inventory and then move it to the Test Folder.
4. Drag the Test Object onto the ground again.
5. Drop a (no copy) item into the Test Object (Please note, you will lose this item).
6. Right click on the object and choose Attach to Left Hand.

At this point the object appears in the Object folder rather than the Test folder where it is from.

7. Detach the Test object.

Just as in other reproductions, it moves out of the object folder to the root directory. Any attempt to move it causes a crash and it disappears when you next log in.

I think it's interesting that if you skip step 5 and simply wear it from the ground, it goes to the Objects folder, but it stays there after it detaches. There is something critical happening when you add a no copy item to the Object. This particular property is making this bug very nasty, causing people to lose HUDs with hundreds of no copy items inside. This bug should be getting the highest priority. It's been around in some form for at least a year. I have personally helped several hundred people who have lost items from this bug.

I'm not able to reproduce at the moment, but will keep an eye on it.

Any ideas??

This bug only affects no-modify objects, but causes no-copy objects to be "lost". Until this fix is deployed the workaround for VWR-6110 problem would be to NEVER attach from in-world – always first take to inventory, then wear from inventory. Unfortunately that does not work for llAttachToAvatar() which only functions for in-world objects.

I believe, the "lost" inventory items are not eliminated from the inventory database, but instead have an invalid "location" record and so don't show up in the inventory view. We have a automatic script that runs in the background and tries to find such objects and restore them to inventory, however I have reason to believe this automatic script is malfunctioning because I scanned Crystals Galicia's inventory and found 112 items that have been lost – I doubt Crystals lost all those today. I'm going to try to figure out why the repair script is broken.

In the meantime (until my fix is deployed) if you have lost inventory items send me an IM asking to have them found and I'll run the scan on your account. Any lost items would show up in your "Lost and Found" folder.

So I don't know... would it be possible to provide a mean (this time intended and documented) to attach something to avatars without adding it permanently in their inventory?

@Satomi Ahn, in theory it would be possible to add such a feature (temporary attachment doesn't go to inventory). Perhaps it is possible today by making a no-copy object that calls llDie() upon login after a logout? Dunno, I haven't tested it.

(1) Intentionally lose some object in-world such that it gets sent into your "Lost and Found" folder. This will flag the directory as having changed and your SL client will download the new list of contents.

(2) Clear your cach via the user iterface (EditMenu->PreferencesOption>NetworkTab->ClearCacheButton) and then logout/login.

Bad News: the deploy of server-1.30 has been delayed one week. It should start deployment around the middle of next week (probably on Wed. Sept. 16).