https://bugs.kde.org/show_bug.cgi?id=411919
--- Comment #41 from flan_suse <windows2li...@zoho.com> --- (In reply to Nate Graham from comment #40) > Maybe we could only do it for encrypted volumes, and for everything else, > the thumbnails could live in the normal location. Nate, from the other bug report I created, all the commenters, as well as myself, are using an encrypted $HOME (which is very common for users who go out of there way to use encryption on external USB, network shares, and secondary drives.) This comes off as a "solution in search of a problem" for such users. We get hit with a performance penalty, sluggish browsing, and overworked CPUs (not an exaggeration, I hear my laptop fans spin up every time I browse a folder with many WEBP images.) Our $HOME is encrypted. There is no risk of spillover. But once again, I must re-emphasize, your philosophy about reducing or eliminating spillover sounds good, but it's not even feasible when you consider network shares. With ubiquitous home solutions of NAS (TrueNAS, Synology, QNAP, etc), and even just SMB / NFS shares in general, KDE generates and *stores* thumbnails from *encrypted* sources. (They are encrypted on the NAS / server.) This is *spillover* if the user's $HOME is not encrypted. The solution should NOT be to read and write thumbnails to a network share. That would be a hard block for me, and I would have to jump to another desktop environment if that ever happens. (Too many reasons to list in here.) ------ So for users that have an encrypted $HOME, there's zero reason to use any sort of sophistication of attempting spillover prevention. No reason to check whether or not the source images and videos live in an encrypted space. No reason to determine the "speed" of the device. Just let thumbnails be cache'd under $HOME/.cache/thumbnails/, like normal. We're using encrypted $HOME for a reason, after all. ------ For those with plain $HOME, you've got an entirely different problem. Try to prevent spillover by forcing the writing and reading of thumbnails to the source folder? But... What happens if there are permission issues? What if the device is read-only (to view, but not modify the images / videos)? Save the thumbnails in each separate folder? Or save them under the root directory? What if the root directory does not have sufficient permissions? (The common r-xr-x--- for root:wheel) Should we try to write and read thumbnail files over a network share? (That's a can of worms...) ------ What I can say confidently for now this is: *** The immediate resolution for users with encrypted $HOME is to remove any such spillover protection. *** Using our computers is becoming a bottleneck when it involves browsing many images and videos. -- You are receiving this mail because: You are watching all bug changes.
