realpath &c (was Re: serious bug. Evolution and Microsoft mentality.)

[Richard Kettlewell <rjk@greenend.org.uk>]

Richard Kettlewell writes:
> Jonathan Walther <krooger@debian.org> writes:

> [...]
> > +	
> > +	/* follow any symlinks to the mailbox */
> > +	  memset(folder_path, 0, sizeof folder_path);
> > +	  if (lstat (lf->folder_path, &st) != -1 && S_ISLNK (st.st_mode) &&
> > +	      realpath (lf->folder_path, folder_path) != NULL) {
> > +	  	g_free (lf->folder_path);
> > +		lf->folder_path = g_strdup (folder_path);
> > +	  }
> 
> This code silently breaks with very long filenames.  As such it can
> hardly be considered a "correct patch"!

Of course the underlying problem is that realpath() has a ridiculously
broken interface: it insists you supply a big-enough buffer, instead
of taking an argument that indicates how big a buffer you actually
have.

Even adding the argument would still leave a poor interface though:
some systems simply don't have a sensible upper bound on path name
size, so you'd have to repeatedly call it with ever-larger buffers,
potentially invoking multiple file system accesses each time.

Rather than just whine about this, and other similarly broken pathname
manipulation functions, I've written some new versions.  You can find
an overview and the (LGPL) source code at:

http://www.greenend.org.uk/rjk/2002/01/pathfns.html

I'd be interested in any comments anyone has, either on the interface
or the implementation.

ttfn/rjk