Re: [Usability] time stamps and privacy

[Jason Hoover <jasonhoover verizon net>]

On Fri, 2008-03-28 at 13:37 -0400, Liam R E Quin wrote:

> > Then why not simply disable thumbnails in the first place?
> Because you want them.

That is something I had overlooked. Perhaps an option to create
thumbnails, but not cache them would also be acceptable? It is important
to note however, that (to my knowledge) many other programs (Image
viewers, GIMP, KDE, etc.) also use this thumbnail directory.
Fixing/modifying nautilus would not necessarily fix the "core" problem
created by the existence of the directory itself.

> > There appears to be some discrepancy and two clear camps. 
> > 
> > The first position is: "I like cached thumbnails and dislike having to
> > thumbnail the same things every time."
> [...]
> 
> > The second, yours: "I like cached thumbnails and want them to be kept on
> > the individual media."
> 
> These are not the only sensible possible approaches.

You're right. There's probably others. These are simply the two main
positions in this thread. There's probably lots more.

> MS Windows (like a number of Unix systems and programs) puts the
> thumbnails on the device, and it would certainly make sense for
> a desktop filemanager such as nautilus to be able to make use of
> "Thumbs.db"; the Mac (both OS X and older) similarly makes a desktop
> file on each drive that we could sensibly use if present, at least as
> a starting point.

Using the existing thumbnails on a volume as a base is a neat idea,
however, the ability to set custom thumbnail sizes by zooming somewhat
hampers it. However I've often browsed directories with thumbs.db files
in them and wondered exactly why it doesn't attempt reading them myself.

> If a device is not writeable, or perhaps if a configuration file is
> present on the device that disallows thumbnails on the device, then
> the thumbnails have to be stored in a cache elsewhere. 

This is presently done, except by default even if the media is writable.

> Said
> configuration file, if it existed, could also give an expiry time for
> the thumbnails, and that would be a useful feature for many people
> (whether managed explicitly via a UI, or per-drive user defaults, or
> whether you have to edit the file), including people who distributed
> DVDs of images.

The idea of an expiry time is already done as well, with the earlier
post in the thread about a patch that causes thumbnails to expire after
long enough. The idea of pre-cached thumbnails is a bit neat though,
however implementing it in a way that doesn't require additional user
interaction to get working right is a tricky one..

> > Scenario number two; even under your system, the potential exists for
> > there to be thumbnails of images which /have been deleted/.
> That's true in all the scenarios.  Checking for it (1) when a device
> is unmounted vie e.g. gnome-mount -u, and (2) when thumbnails are
> accessed, and of course (3) when images are deleted, may help.  It
> doesn't solve it 100% as you can use command-line operations to unmount
> a drive, or just pull it out, or there can be a powr failure. 

Expiry is already sort of handled in the aforementioned patch. If the
thumbnails are stored in a remote location that is not always easily
accessed, the entire media would have to be scanned every time it
becomes available just to remove the related nonexistent thumbnails.

With a central storage location, the media is not required to detect
'oldness', and they can be removed on a periodical basis. Furthermore,
having to check for/delete a thumbnail every time a file is
deleted/moved is at best, extra CPU cycles that don't have to be
consumed - or at worse additional network traffic that does not have to
take place.

There is also a serious problem with nautilus trying to use the 'root'
of a drive. In many cases the 'root' of a network drive is not
assessable or even determinable. In fact, the root of any properly
configured system is not assessable either. In the case of the network
volume in your example, nautilus might create thumbnail directories on
individual shares - or worse - sub-directories of shares which were
mounted directly. Of course, this could be avoided by simply storing
thumbnails on a local directory for networked volumes, again however,
this is already the case.


-Jason

PS: Sorry Liam. Meant to reply to all. Whoops.
PPS: Man, I really suck today. Need more coffee.