[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A few issues with thumbs.el

From: Juanma Barranquero
Subject: Re: A few issues with thumbs.el
Date: Thu, 26 May 2005 20:22:35 +0200

> Oh, right.  So the docstring should be fixed to make it clear that the
> argument should be an *absolute* file name.

Uh? convert-standard-filename works right with non-absolute paths:

(convert-standard-filename "file/test:.dat") => "file\\test!.dat"

It just handles an initial "X:" differently (on Windows):

(convert-standard-filename "c:file/test:.dat") => "c:file\\test!.dat"

I see nothing wrong with convert-standard-filename or its docstring.

AFAICS, the problem is that convert-standard-filename is intended to
transform a filename into another filename, suitable for the current
filesystem. But what you're trying in the code you proposed is using
convert-standard-filename to build the *name* part of a filename.

There's nothing anywhere that guarantees that a filename (with path
etc) is a valid name for a file. In MS-DOS/Windows you've got the ":",
in VMS the brackets, etc. When you concatenate thumbs-thumbsdir with
the output of convert-standard-filename, the result can perfectly be a
non-valid filename.

So you'll have to use convert-standard-filename, and then filter its
output to remove potentially dangerous characters, or, as I did in my
example, use convert-standard-filename as the last pass:

  (convert-standard-filename (concat thumbs-thumbsdir "/"
(subst-char-in-string [etc...])

I don't think the trouble is worth the tiny benefit that the filename
of the cached thumbnail is user-friendly on debugging. If someone has
to debug it he can modify thumbs-thumbname easily enough.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]