VFS: understanding the Index file layout

On this page you can find a short description of the index file layout including some basic nice to knows. This is valid upto 1.13.2. Latest first look viewer 1.13.3(57575) has a radically different way of texture caching which leads to new observations.

The index-file contains 34-byte long records which contain the following fields (listed in order):
Location (4 Bytes): The location within the cache file counted in bytes from start of file.
Length (4 Bytes): The reserved amount of space in the cache file for this item, counted in bytes (multiples of 1024 as 1024 is the block size)
Accesstime (4 Bytes): Timestamp of last access, is updated when file is read from cache and is set on intial addition in the cache. Counted in seconds since 1/1/1970 (commonly known as unix time or POSIX time)
UUID (16 Bytes): The unique ID of the asset
Filetype (2 Bytes): The asset type, mostly 0 (textures)
Size (4 Bytes): The size, counted in bytes, of the data currently stored for this asset. This can be significantly lower than the Length

Loading the world with a blank cache and subsequent analysis of the index file shows that the caching system is very inefficient. Due to its implementation files can not be stored fragmented hence the expected required amount of space is immediately reserved in the cache. Yet most files are not download in their entirety. Just a few minutes after login a clean cache will have over 50MB of cache reserved which means small caches are totally pointless as it'll start removing items shortly after you start the client.

NOTE:As said above, as of 1.13.3 the system changes radically and the newly implemented texture cache is a lot more efficient. This documentation should hence be revised as soon as more info is available on the new implementation.