bug#8035: Processing of .. in a file path after going thru symlink

[Lars Ingebrigtsen]

spucci <slpnabble@blackberry-hill.com> writes:

> When emacs attempts to find a file with "../" as a path component, it
> appears to be "smart" about it and simply remove the previous directory path
> (e.g., "foo/bar/../x" gets converted to "foo/x").  But if bar is a symlink,
> then it doesn't properly find the file.  So in compiler output, which
> references such files, the next-error function fails to find the file with
> the given name. 
>
> mkdir dest 
> mkdir dest/subdir 
> mkdir src 
> ln -s ../dest/subdir src/subdir 
> echo "#error This is an error" > dest/foo.c 
>
> Now M-x compile, and give it cc -c src/subdir/../foo.c 
>
> *compilation* buffer has: 
> cc -c src/subdir/../foo.c 
> src/subdir/../foo.c:1:2: error: #error This is an error 
>
> and do a next-error: Emacs complains it can't find the file. 

This is an even more foundational problem:

(file-exists-p "/tmp/comp/src/subdir/../foo.c")
=> nil
(file-truename "/tmp/comp/src/subdir/../foo.c")
=> "/tmp/comp/dest/foo.c"
(file-exists-p (file-truename "/tmp/comp/src/subdir/../foo.c"))
=> t

And this is because:

static Lisp_Object
check_file_access (Lisp_Object file, Lisp_Object operation, int amode)
{
  file = Fexpand_file_name (file, Qnil);

I'm guessing it's calling expand-file-name here to resolve "~"?  It's
also a micro-optimisation, I guess -- collapsing "parent/.." textually
without checking the file system is very cheap.

But...  this does mean that `file-exists-p' and friends are unreliable
in the presence of symlinks, which is pretty depressing.  I think that
`expand-file-name' call in check_file_access should be changed to
something that just does the "~" expansion.

Any opinions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no