In machines with limited memory there tend to be more inventory problems because of a crash while the viewer is closing. Latif Khalifa, Singularity & Radegast TPV Dev, explained that as the viewer closes it compresses the inventory list and saves it in the SL cache folders. (Those are the files with names ending in inv.gz.)
I’m not that into what this part of the viewer is doing or how it does it. Hopefully I have this mostly right.
If the system is almost out of free available memory, the task crashes as runs out of memory needed for the compression process. The result is not noticeable until the next login when parts of the inventory are missing. Of course the files can be rebuilt from the SL server and the inventory is not really missing, the viewer just thinks it is.
If a person is using a 32-bit machine, the current viewer has memory leaks, and they have a good size inventory they will probably hit this problem.
Most people would never notice the crash on viewer close. If they do, they may not care. They will however notice an inventory problem if it is there at the next login. But, they probably won’t associate the two things.
What can you do to mitigate the problem? Get off Windows XP and switch to a 64-bit operating system (OS). Short of that there is little you can do to avoid having the problem.
If you are seeing this problem and having consistent inventory problems, you could try removing the [?].inv.gz files from the cache before you log into SL. This will get rid of the broken file(s). The viewer will go to work downloading a new inventory list on your next login. It may take longer for your avatar to rez, but it, at least, should rez.
The Lab is looking into the problem. One suggestion has been to move away from the GZ compression format and use the ZIP format. Then the file could always be in ZIP format and the Windows system could then handle the compression as an ongoing task avoiding bulk compression on viewer close.
Whatever, there will probably be a fix as this is a problem common to 32-bit systems running SL.
Of course fixing the memory leaks is the more desirable solution. But, the Lab is always fixing memory leaks. They are a consistent problem of software development. New code often adds new memory leaks. So, even if the old leaks get fixed we can always expect new ones to pop up. This means a fix to this specific compression problem needs to be found and until it is some will have to deal with it.
I’m yet to see such an issue happening (at least with my viewer): when the viewer closes, it frees a lot of data structures (and especially, textures and objects data gets freed at a very early stage during the shutdown), so it also frees a lot of memory and it is *extremely* unlikely that a crash will happen at this point because of an out of memory condition…
My guess is therefore that affected viewers have got other \crash on shutdown\ bugs (there have been many of them in v2/3 viewer code, and I fixed dozens myself in the Cool VL Viewer: the latter now always closes down cleanly, but it has not always been the case in the past).
IVE HAD A PROBLEM IN MY INVENTORY FOR A LONG TIME, I HAVE TWO TRASH BENS AND TWO OBJECT FOLDERS. I CANT EMPTY MY TRASH CAUSE IT COMES RIGHT BACK IF ANYONE KNOWS THE ANSWER LET ME KNOW
That type of problem requires SL support to run a script. Any problem where system folders are messed up requires a fix from the Linden side.