Re: symlinks, thumbnails and minor irritations

["Shahms E. King" <shahms shahms com>]

On Mon, 2004-05-24 at 11:46 +0200, Alexander Larsson wrote:
> On Mon, 2004-05-24 at 00:01, Shahms E. King wrote:
> This has been hotly debated before. See the list archives. The decision
> last time was to not follow symlinks, but introduce "shortcuts" into the
> ui that are resolved upon activation.

I looked through bugzilla and the archives but didn't find anything
relevant.  I will look harder...

*snip*

> Yes. This is a problem with the way the spec works. We could do better
> in some cases, if the change is made through nautilus. If someone could
> work on that that would be nice.

Would you accept a patch that resolved symlinks in the path after
failing to find a suitable thumbnail with the original? I'd think hard
or symbolically linking the equivalent thumbnails might also be
reasonable to avoid the second check in the future.

> > From reading the thumbnail spec, it appears as though at least some of
> > this is "desired" behavior.  Yes, md5summing the canonical URI to a file
> > means thumbnailing can work for any type of resource and speeds up
> > thumbnail generation for the common case. But it also breaks horribly in
> > a number of other cases and seeing as you're going to have to download
> > the remote file to thumbnail it anyway, shouldn't the md5 of the actual
> > file be used instead? Or at least as a backup:
> 
> Eh? md5suming a file means reading all of it. Thats basically as slow as
> thumbnailing a whole image, and typically *much* slower than
> thumbnailing a video (that only reads some initial frames).

Yeah, I knew it entailed reading the entire file, just figured it would
be faster anyway, but after a few 'time'd runs locally, this won't work.
Well, it'll work, but it doesn't buy anything.

I'm almost tempted to suggest an inode/device cache of some sort for
local files.  That might also solve a number of issues with removable
devices as well...

-- 
Shahms E. King <shahms shahms com>