• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Upvote the ".thumbnails too big" bug report so Google might fix it [PARTIALLY SOLVED!!]

K

kurkosdr

Newbie
EDIT: PARTIALLY SOLVED!!

If your android device uses a filesystem that supports sparse files, the zero (null) bytes don't actually occupy any space.

More info, and instructions on how to see how much space is really occupied by thumbdata3 (no root needed):
https://code.google.com/p/android/issues/detail?id=39546#c79

The difference between the size ls/filemanagers report and the size actually occupied (as reported by du), is huge for the thumbdata3 files! My thumbdata3 files occupy only half a megabyte of actual space (note: for the .jpg files, size reported by ls and and size reported by du should be about the same).

(also, ls lists sizes in bytes, du lists space occupied in kilobytes, also du tends to round the size upwards a bit, usually by 1-2kb).

This is the reason we didn't reclaim any free space when deleting thumbdata3. There is no significant occupied space to reclaim :o

Note: The only devices that 'll have a problem are devices using the FAT32 filesystem, which does not support sparse files. If size reported by ls and actual size reported by du is the same for thumbdata3, it means you have a FAT32 filesystem, post the name of your device so the rest of us can avoid that device.

--------
Original message:

Hi there,

For those not familiar with the issue, the .thumbdata3 file inside DCIM/.thumbnails can get too big (over 1GB in size and sometimes 2GB) because it keeps info about files you have deleted from the phone (note: you may have to enable "show hidden files" in your filemanager to see the file). Also, in some phones it's not really deletable, aka you don't get any free space back if you delete it and it reappars.

There is a bug about the issue here. It only has 40 stars as of now, so if you find this bug annoying and want to urge Google to fix the issue, you may want to upvote (star) it.

Cheers.
 
Just had a look and mine is 27mb lol uploadfromtaptalk1393267725314.jpg
How many pics would you have to take to get 2gb?
 
funkylogik said:
Just had a look and mine is 27mb lol View attachment 68009
How many pics would you have to take to get 2gb?
Click to expand...

First of all, you are probably using an older version of Android. Versions from 4.2 and onwards don't have a /mnt/sdcard/ directory They have a /storage/emulated/0/ directory ( /mnt/sdcard/ redirects to /storage/emulated/0/ )

Anyway, I 've noticed that old versions (like he 2.3 my Optimus 2X runs) store their thumbs to Android/data/com.cooliris.media/cache in two folders called localimage-thumbs and local-video-thumbs respectively. Note that com.cooliris.media can be com.android.providers.media in some phones. The .thumbdata3 file is hence very small (on my 2X it's 1.05MB).

For 4.2, the thumbnail cache tends to get big if you create and delete lots of files. It gets bigger when you take a photo, does not get smaller when you delete one.
 
latest version mate. 4.4.2 uploadfromtaptalk1393274992272.jpg
I dont take many pics mind you but theres nearly 1000 files there.
So how are they deleted permenantly? Does it have anything to do with g+/picassa?
 
KitKat here too. Interesting that you have 2x as many files but my folder size is 10x larger.
 

Attachments

  • 1393275410475.jpg
    1393275410475.jpg
    46.8 KB · Views: 122
That is strange. Youd think all thumbnails would be the same size?
Im guessing these are all pics i have on g+? Theyre no longer on my phone.
So turning off pic sync would stop them using up storage?
 
Hmmm uploadfromtaptalk1393278061598.jpg
This is my tab on the same account so I'd have expected it to be the same but it has far less files using much more space :confused:
 
Im guessing thats why then mate(?)
All my pics get synced/uploaded to google+. I dont fully understand how it works though lol
 
Guys, I don't think it matters how many files you have in your device now. It matters how many files have passed through your device.

Each file is assigned an ID number, which is not reused if you delete the file. So, as you create and delete files, the ID gets larger, and the .thumbdata gets larger (which is mostly null bytes, see link below and you 'll understand why)

A neat explanation (from reading the source, not a wild guess) can be found in this thread (link to specific post).

So, if you delete and create many files, you 'll encounter the bug, so go to the link in the first post and star it if you want to see it fixed.
 
What happens if a file is made for the init.d folder to delete cache and junk files that make up those thumb nails . cause I would think if the device is forced to do a clean out from the init.d wouldn't this keep them thumbnails low and more space to play
 
funkylogik said:
And how do they regenerate when wiped? I still dont understand that. The data must come from somewhere?
Click to expand...

-First of all, some devices don't really delete the file (you can tell because you don't get any space back).

-Secondly, the .thumbdata3 is mostly junk (zeros). Think of it like padding the file with junk (zeros) for the first 1GB, and then you put 10KB of real data to the end of the file. So, you don't need much data to create said 1GB file, just 10KB.

-Now, as I said in the previous post, Android assigns an ID (a unique number) to every file. The maximum ID assigned dictates how long the padding-with-junk will be. If you are unlucky and the maximum ID for your device is for example 90000, then the padding-with-junk will be 90000 * 10KB (see note 1) aka about 1GB. So, even if you delete the .thumbdata, if you don't find a way to reset the ID assigner, you will end up with a file just as big (android will recreate the file, and it will pad-with-junk again). Also keep in mind that if you are unlucky, you can get such a huge ID even if you don't have nearly as many as 90000 files on your device.

This is a much bigger bug than people think it is. If you are unlucky and get a big maximum ID, your thumbdata will get huge, period. Sizes of 2GB and more have been reported. Very shoddy coding from Google's part.

PS: Took a quick glance at the source, couldn't find info how IDs are assigned, the id is passed as a value by another class.

note1: according to the source code, the actual value is not 10KB, it's 10000 bytes so the actual padding will be 90000*10000 bytes
 
funkylogik said:
Cool. So is there a way to find out what our "id" is?
It must be far longer on my tab than on my phone
Click to expand...
As a sidenote, what is your tab and what is your phone? Are they the ones listed on the left? I am trying to figure out whether having a device with an external SD card slot can result in high id's (which would add to the problem of id's of deleted files not being reused, in fact, it could be a worse problem).

Each thumbnail occupies ~10KB, and my thumbdata3 is 1.4GB, so I am having a difficulty believing that 146801 files have passed through my device. I don't shoot many photos and don't uninstall/install apps often. My guess is that if your device has an external SD card and is not mounted under internal SD, some ridiculously high id is given to the files of the external SD. This would also explain why thumbdata3 is 99% zeros.

PS: No clue on how to find the ID. And you can't reset it either. I tried everything, like force stop, deleting data and cache and turn off for the Media Storage and Gallery apps, and then deleting the file. No dice, still didn't get free space back. Don't try this! In fact, now the file appears as only 27MB, but the free space is gone. :( Remember the days we had USB mass storage mode?
 
I tagged the issue as "partially solved", because that nonsense with zero bytes in thumbdata3 is still silly, and devices with a FAT32 filesystem still have the problem.
 
You must log in or register to reply here.
Back
Top Bottom