https://bugs.kde.org/show_bug.cgi?id=443806
--- Comment #4 from flan_suse <windows2li...@zoho.com> --- (In reply to Lemuel Simon from comment #3) > If you don't mind me asking, what is your partition scheme? Gladly. I'll keep it simple and laid out, so as to make it easier to follow and compare. Just FYI, I do not use LVM whatsoever. The following sources have multimedia (picture and video) that support thumbnail previews. SRC1, Single local partition (entire system, /boot, /, and /home) | encrypted (LUKS) SRC2, Single local partition (external USB) | encrypted (LUKS) SRC3, Single local partition (external USB) | plain SRC4, Network share (CIFS) | encrypted (ZFS) --- When using Dolphin to browse images/videos in SRC1, SRC3, and SRC4, thumbnails are generated and CACHED under ~/.cache/thumbnails With subsequent re-visits of these folders, the thumbnails are QUICKLY displayed (because they're loaded from cache) Examples including ~/Pictures, ~/Videos, a CIFS share mounted via "cifs" from a server, a USB stick with pictures, et al. Because /home resides within an encrypted partition, there is no risk of "spillover" of sensitive thumbnails jumping from an encrypted source to a plain (non-encrypted) ~/.cache However, if my /home actually lived in a plain (non-encrypted) partition, SRC4 is an example of "spillover" of sensitive thumbnails being cached to a non-encrypted ~/.cache (yikes!), whereas the original photos are stored encrypted (on the server). --- When using Dolphin to browse images/videos in SRC2, thumbnails are NOT cached under ~/.cache/thumbnails With subsequent re-visits of these folders, the thumbnails must be re-generated all over again... every... single... time... --- This bug report (feature request) is to give users, like you and me, an option to toggle this behavior. Keep the default as it is, but give us the option to allow thumbnail caching ALWAYS (regardless if the source multimedia lives in an encrypted space.) * It would be much faster (rather than always re-generating the thumbnails from scratch) * Very important when dealing with numerous files in large folders * It's not necessary to protect from "spillover" if your /home lives in its own encrypted space anyways (such as /home in LUKS) * It's not even implemented properly anyways, as seen with the example of SRC4 above -- You are receiving this mail because: You are watching all bug changes.
