https://bugs.kde.org/show_bug.cgi?id=411919
--- Comment #27 from flan_suse <windows2li...@zoho.com> --- (In reply to Marcin Gurtowski from comment #26) > > 2) The user's $HOME is where we expect cache to be consolidated, and it's > > the main "driver" of daily work. I'd assume most users that utilize > > encrypted volumes use them nearly exclusively on their *own* system, rather > > than on someone else's system. It can complicate things if KDE is an outlier > > in that it caches thumbnails on the folder/volume itself (where the media > > resides), while other desktop environments continue to use $HOME/.cache > > consistently. > > If someone uses both unencrypted $HOME and some encrypted devices, it > implies they don't care as much about data from $HOME being leaked as they > do about from encrypted media. Catching data from encrypted drive gives > access to data that shouldn't be given. But that once again stresses the importance of user-choice. If KDE *hard-locks* a user to one method or the other, based on the encryption (or lack thereof) of their $HOME, then the user is stuck with the developer's decisions and has to either (1) "live with it", or (2) find a hacky workaround, or (3) file bug reports and wait for the changes to be reverted/fixed upstream. Some user's *without* encrypted $HOME may prefer performance over spillover prevention. While some might not even care. While yet some still might want zero spillover. Guess what solves all of the above? An option that can be toggled. ;) As for users *with* encrypted $HOME? Providing the same toggles does no harm, and it still gives them a choice if they so desire. "Oh, but what about network shares and NAS servers?" Since KDE is unaware of whether or not the files are encrypted on the server, there should be no fancy workarounds or guessing. Once again, an option that can be toggled resolves this issue. No one needs to ask "How can we determine if the files are encrypted on the server? Maybe we should assume they are or are not?" A simple toggle solves this. No one is hard-locked into anything. As for the "default" setting? Err on the side of caution. Have the toggles default to *DISABLED*, and let the user decide if they want to enable them. No need to deviate from the other desktop environments and OSes by writing thumbnails to external media and network shares. For the record, I would *NOT* want KDE to store thumbnails on my external drives and *DEFINITELY NOT* try to store them on my network shares. If KDE tries to go the route of "We'll just save thumbnails on the filesystem from where the images/videos reside", it can really open up a can of worms down the line... I listed out *four* independent issues of concern if pursuing this approach. (I even thought of *more* reasons off the top of my head just now.) > I'll try to look into the problem and fix previous solution (create > thumbnails, but don't save them), but if you want to add extra options to > this, is sounds fine to me. I truly, truly believe the two toggles mentioned above would resolve nearly all user scenarios. -- You are receiving this mail because: You are watching all bug changes.
