[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations
Payton Q
bugzilla_noreply at kde.org
Mon May 15 07:00:57 BST 2023
https://bugs.kde.org/show_bug.cgi?id=443806
--- Comment #32 from Payton Q <pmquinn5 at proton.me> ---
I think the reason for the disconnect here is that there are two different use
cases:
Some people use encrypted drives in a static fashion. As in, it's always
attached to their machine.
Other people use encrypted drives in a more "moveable" fashion. As in, it's
either an encrypted volume that they can move around (as in KDE Vaults), or
it's a portable drive they take with them to other machines.
For the first group, if the home directory is encrypted, then there's no
downside to storing the thumbnails in the usual location in the homedir.
However, there would be a downside to storing them on the separate drive, for
the reasons listed above.
However, for the second group, it's the exact opposite. For people who use
their encrypted volumes in a portable manner, storing the thumbnails on the
drive itself has no downsides. If the freedesktop spec was updated to permit
it, then any other compliant machine they take their drive to would check on
the drive itself to look for thumbnails. However, storing them in the homedir
would have a downside, as the thumbnails would need to get regenerated every
time the drive is used on a new machine.
The problem is that based on the thumbnail spec provided to me by Nate, what
the first group is advocating for is compliant with the existing thumbnail
spec. I suggest that we go ahead with the fix I proposed on my merge request.
Namely, for any encrypted volume whatsoever, if the homedir is encrypted, store
the thumbnails in the homedir per the spec. Then, if we want to pursue a change
to the spec, we can have that conversation separately. In the meantime, I don't
think it's fair for kde users nor is it a good look for kde to remain
noncompliant with the spec and leave users without basic functionality for so
long.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the kfm-devel
mailing list