Benedikt Meurer wrote: > Stanislav Brabec wrote: > > - Image files in public directories are thumbnailed many times: > > once for each accessing user. > > Sharing thumbnails might be a security problem.
Not bigger problem than sharing any other images - any image loader must be written as a secure code. Thumbnail loader must be written as a secure code, too. Additional security problems I can imagine: - Anybody who has permission to change image can also upload false thumbnail. - It local thumbnail directory does not exist, it's easy to DoS it by using bad permissions for mkdir. Note that creating of false thumbnails is already possible in Nautilus by playing with time stamps. > > - Thumbnails on removable media are thumbnailed many times: once for > > each machine, where medium is accessed > > IIRC the standard already covers this, tho it's not implemented in Xfce > and GNOME. Yes, shared thumbnails are part of the spec. But if they are not present on the medium, it has another problem: Depending on OS, it may generate thumbnails again and again for each drive to which medium is inserted and vice versa it can overwrite cached thumbnails from one medium by thumbnails for another medium: Imagine following schema: One medium has: /mnt/cdrom0/pict0001.jpg In the different drive it's thumbnailed as a different file: /mnt/cdrom1/pict0001.jpg Another medium has pict0001.jpg, too: /mnt/cdrom0/pict0001.jpg After inserting to the drive, it will invalidate thumbnails of the previous medium. >> - Thumbnail files are often larger than images itself, especially for >> jpeg images below 20kB in size. > >The software can detect this and load the JPEG directly. Yes. This information can be cached to not try to thumbnail it again. The same is valid for images with embedded thumbnails. > > - There is a very small chance to detect deleted images and delete > > corresponding thumbnail. > > The file manager should clean up the thumbnails when deleting files. Not only file manager is allowed to delete files. Using rm or viewing temporary images ends with orphan thumbnail. Cleaning them requires to check the whole cache (or file system) and can potentially delete all thumbnails of not inserted removable media. Well, in this case inode concept does not work well, too. Only local thumbnails or xattr thumbnails can perform better. > > Use unique inode_number/volume_id instead of file_path. > > This will not work with certain FUSE file systems, that generate unique > inodes on-demand, because it's likely that the inodes will be different > each time the file system is mounted. But there is still a chance to detect it and fall back to file names on such file systems. For example ISO 9660 does not allow to detect hard links and some file systems may return different inode numbers for different OSes. > > Haw widely used desktop-neutral thumbnailing library understanding many > > embedded thumbnails and providing thumbnailing for images without > > embedded thumbnail. > > I think external thumbnailer as used by Thunar/Nautilus are better, > because it's more flexible and avoids loading various libraries required > to generate thumbnails for different formats into the processes. External binary thumbnailer has to initialize and load needed libraries again and again for each image. If you will have library, you can manage this better by using shared modules. For example you can load them on demand and unload after finishing of thumbnailing of the directory. For typical small and simple thumbnailer it saves only few milliseconds per image, for thumbnailers preloading larger libraries it may be more. > Using .desktop files to register thumbnailers instead of GConf should be > fine for desktop-neutral usage. I agree. Additionally GConf has no way to solve more-thumbnailes-per- MIME-type problem (later wins), desktop files can solve it (by mechanism of choosing defaults). > > Allow jpeg thumbnails. > > Aside from maybe a few bytes saved per thumbnail, why would you want to > do this? Few gigabytes saved per whole file system. Imagine data on my hard disk. I have about 4000 images in the photo library. Each image has 10 hard links depending on sorting criteria (by topic, by place, by date, by topic & place, by topic & date,...). The archive directory is accessible by two paths (direct, using symlink from Desktop), each image is viewed by at least 2 users. It may result with 10 x 2 x 2 x 20kB = 800kB of thumbnails per single image! > > Thumbnails can use file system extended attributes. > > Not every file system supports that. What would be stored in the > extended attributes anyway? If file system has extended attributes, maybe you can use them to store thumbnail. I am not sure about xattr limitations, but Apple's HFS uses something similar called resources to store thumbnails. If file system does not support it, the fall back to other methods. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
