When does a texture get deleted off the server?

My understanding is that the Inventory is a set of pointers to resources held on servers. If I delete an entry from my Inventory, of something I have uploaded (so I know no-one else has the same reference), then will it get deleted from the server?

To test this:

I uploaded a texture, copied its UUID to the clipboard;
deleted the texture from my Inventory;
cleared cache;
logged off;
logged back on;
created an object;
created a script to apply the texture using the UUID from the clipboard;
the object shows the deleted texture.

So, does it ever get deleted from the server?

As far as I can tell, a texture remains in the main LL inventory servers for eternity... or until they crash unrecoverably...

Deleting a texture from *your* inventory, even if you are the creator of it, is no clear indication that other items don't already exist in SL that use that same texture. If I textured a bridge on your property with custom textures that I designed and which "existed" as textures only in my inventory and on your bridge, which would you prefer to happen, if I later deleted those textures from my personal inventory?

A: The textures still remain in the LL master asset servers, and so your bridge remains nicely textured.

B: The textures have been deleted from my inventory, and thus cease to exist in SL. The bridge you bought from me becomes textured like plain plywood again.

I think most people would choose option "A", don't you?

On the other hand, as a texture designer I certainly would LIKE to be able to eliminate a texture that I just created and that I know will NEVER get used, such as a texture that should have had transparency, but which accidentally got uploaded from a 24-bit source and is thus opaque in the intended transparent areas... But there is no option in SL to do that, even though it would save a little strain on the asset servers.

I believe there is a process which is supposed to remove textures for which the last reference has also been removed. In other words, once there are no other objects in the database which reference the texture, after a period of time, this texture is removed. I do not know if this process looks at UUIDs in scripts as well. It seems I remember Linden Lab suggesting that the frequent "missing texture" issues were being caused by overzealous garbage collection. I will see if I can find these posts.

You'll have more luck searching for the proper term: garbage collection

Or reading through /341/f6/180986/1.html should give you the gist of it .

Garbage collection is fairly taxing so it only runs periodically and in the case of a texture it would only be eligable if:
* no prim exists with that texture applied (rezzed or non-rezzed)
* no clothing/body parts exists with that texture applied
* it's not present in inventory (either resident inventory or prim inventory)
* no script exists that contains the UUID of the texture

I probably missed another one .

As I understood it, the "Garbage Collection issue" had to do more with the asset data stored locally on a single sim's server, relating to what was in that sim, and not the main asset database. You could never safely assume a texture is not in a script somewhere, referenced by UUID. So I don't see how they could ever do an automated sweep of the asset servers to eliminate an "unused" texture...

This is the post I was referring to:
/139/62/137077/1.html#post1284267

Thanks Persephonie,

Just re-read that old post, and I gues the others were right. But it still seems to me to be an impossible task to check the content of every script in SL for references to possibly unused UUID's...

Ah, but they do. And they know they cannot do a perfect job of it. See Kelly's comments on this:

A quick search doesn't turn it up but I'm pretty sure LL has said that they do scan scripts for asset UUIDs but it's possible to miss them by doing silly things like...

string a = "a822ff2b-ff02-461d";
string b = "b45d-dcd10a2de0c2";

key k = a + "-" + b;

I'm not sure if they actually scan scripts or if something in the LSL compiler keeps track of keys used in the script and just tells the GC what it found during compilation..

Yes, I agree. And what is worse, UUIDs can be generated dynamically, or read from a notecard. It is certainly not a perfect system. Hard to imagine a perfect system really.

If they're in a notecard, that's a reference and *should* keep the GC from cleaning it up.

Can they be generated dynamically?

I tend to doubt that they would be searching the full text of every notecard in the database for a string of characters that appear to be a UUID. It's easier with scripts because they are compiled (tokenized) and references into the database are probably stored in a more compact long integer format.

Sure You did it in your post above.

Why not? Unless they're rebuilding all the ref counts from scratch - ouch! - when they run the GC, it would just have to scan notecards & scripts when they get saved..



Nope - I copied it from the wiki because I couldn't remember the format. Just making up a UUID doesn't buy you much..

Thanks Persephone for your helpful reply!

The Kelly Linden post was very useful.

Benja

SL does an amazing job with textures, in just about every area.

Scan every notecard when saved, on the very unlikely chance it contains text that could be a UUID? Well, I suppose anything is possible. They could even offload that job to the client. Just seems like a pretty wasteful use of processing power - whether mine or theirs. I still suspect they are not scanned, but you may be right.

I think the lesson to be learned here is to never upload nakie pictures of yourself to the asset server, because you never know if or when they will be deleted. I sure wish somebody had told me this years ago.

It has to do with the way assets are stored in the database. As far as the asset server is concerned, a notecard isn't just a notecard. Even if it doesn't have attachments, the UUID for the notecard is related to the UUIDs of the creator and the owner. If it does have attachments, those attachments are likewise saved as UUID relationships. The same thing is true for an object with textures, an object or avatar with inventory items, etc.

I don't know what SL's asset server database architecture is, of course, but it would most likely look something like (a much more complex version of) this:

Assets table
-------------
GUID................NAME........................TYPE
abcd-...............Annie's Notecard.......Notecard
efgh-...............Annie's Texture..........Texture
ijkl-.................Annie's Texture 2.......Texture


AssetInventory
--------------
PARENTGUID................CHILDGUID
abcd-...........................efgh-...
abcd-...........................ijkl-...


Apologies for the mess - the no-BBCodes thing is a pain.

This information gets stored in the database when the notecard is saved (although obviously the texture asset information would already be there).

To check whether "Annie's Texture" is in any object's inventory, they just have run a single database command. Even better, they can run a single database command to quickly find ALL assets in the Assets table which don't show up as children in the AssetInventory table and mark them for deletion at the same time. The actual Garbage Collection process is probably a bit more involved, but I'm fairly certain that it follows this basic idea. Relational database systems like mySQL are optimized for exactly this sort of thing - it's unbelievably fast.

Well, some of the earliest textures in the asset server still exist, so I doubt many get removed.

/54/e1/47922/1.html