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.