How does Linux store thumbnails ?

SkyHiRider

I recently noticed that KDE creates a .diretory file to probably store info about thumbnails and other stuff and Gnome does store thumbnails in a centralised directory.

Can anyone elaborate this difference in more detail and compare the benefits and drawbacks of each approach?

Goineasy9

Both KDE and Gnome save thumbnails in hidden home directory files. I don't really see any big difference between the two. Maybe you can elaborate why you think there is a difference and explain in what context you think doing it a different way could have benefits.

SkyHiRider

Well for one I thought that KDE will save a single hidden file to every directory that has thumbnails, as compared to Gnome that has a global .thumbnails directory that stores all the thumbnail files.

I'd personally like the Gnome approach better as when you need to delete the thumbnail files you can just delete one directory an you're done. I also wonder ,if KDE creates only .directory files does it recreate thumbnails every time I enter a directory or does it have a similar global directory like Gnome?

mfillpot

KDE does have a global thumbnails directory, it is {HOME}/.thumbnails. The .directory file you see in your picture directories contains the file browser preferences for that directory, The extract for a .directory file is below.

[Dolphin]
ShowPreview=true
Timestamp=2010,2,6,10,35,10

SkyHiRider

I realised that Doplhin creates a .directory file, I'm just surprised that Nautilus does not create any file. Was wondering how does Nautilus know which thumbnails are created and which aren't and how does it know the preference for each directory (where and how does it store it's thumbnail setting database).

mfillpot

Ok, I got an answer, but not the complete answer.

The thumbnail function is the same for both kde and gnome, the thumbnail image is created and named based upon a hash of the original file or file path or something (I haven't quite found yet). But the hash of some value is used to generate the thumbnail name for each file.

SkyHiRider

Interesting. So basically when Nautilus or Dolphin go to a directory, they create a hash of each file and look into the .thumbnails directory if it contains the said hash. If it does they show the thumbnails of the file (or don't if it's in the no thumbnails directory), if not they will generate both the hash and a small picture as a thumbnail and put it in the .thumbnails directory.

But I still don't get why Dolphin creates a .directory file. If it's not for thumbnails then for what?

mfillpot

The information about the thumbnail management use by freedesktop.org window managers is at http://jens.triq.net/thumbnail-spec/introduction.html.

You have it, the hash is normally generated by referencing the file path and modification time, but other apps may make thumbnails in which the hash includes additional information like the camera model, resolution, etc...

The .directory file is used to store the view properties for the directory that contains the file. That file is used to store the following for each directory:
[ul][li]view mode[/li][li]if previews are enabled[/li][li]when the view mode was last modified[/li][li]if hidden files should be shown[/li][li]if it is set to display the contents sorted[/li][li]sort order[/li][li]If the files will be grouped[/li][li]the icon associated with the directory[/li][/ul]

Other options may also be stored in the file, but I have not yet identified them.

Shown below is the contents of a .directory file with grouping, sorted entries, previews, to show hidden files and icon view enabled.

[Desktop Entry]
Encoding=UTF-8
Icon=user-desktop
Type=Directory

[Dolphin]
CategorizedSorting=true
ShowPreview=true
SortOrder=1
Sorting=2
Timestamp=2010,2,7,11,14,9

[Settings]
ShowDotFiles=true

After looking all of this up I am impressed with the work of the freedesktop.org community, this is a good method that is built for efficiency and accuracy, but it is still prone to duplication of thumbnails if the same file is present in multiple directories, which is probably why it is just a proposed standard at this time.

SkyHiRider

Thanks for the breathtaking reply, this is exactly what I was looking for!