Pat Suwalski wrote:
Stanislav Brabec wrote:
0. Try to embed thumbnail into the file, which supports it, if user
explicitly wants it.

1. Try to use xattr or resources, if file system supports it and it
allows large enough data (may fail often)

2. Try dotted local directory (may fail on FAT)

Once again, this is a terrible idea. It's where Microsoft got it wrong with the hidden Thumbs.db. Extremely awkward when copying directories around. There should never be any extra baggage around my files.
Storing the thumbnails on the volume is the only safe way to produce thumbnails for encrypted devices (see below). It has it's advantages too - they don't have to be regenerated on each machine using the volume, so you trade a little disk space for cpu cycles.


It is already hugely annoying that "deleting" a file on my camera in Nautilus moves it to some hidden Trash directory on the memory card.
It is a bit, but there is no other way of having a trash folder for removable media and not posing a threat to security for encrypted devices. Sure a thumbnailer could try and detect an encrypted volume and just turn off thumbnailers... but how would you futureproof that? In five years time folk might not be using cryptsetup-luks. Even if you get in-kernel support for this (i.e. a list of encrypted volumes in /sys/ or a new mount option: "no-thumbnail") that doesn't interoperate too well: the bsd folk might want to use the thumbnailers.

3. Try another specified directory (may fail on read only)

4. Fall back to global user cache in ~/.thumbnails

--Pat
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to