Re: Wierd bug report: /usr/share/.. = / ???
On 04/08/02 13:25:39 -0400 Adam C Powell IV wrote:
Michel Dänzer wrote:
On Mon, 2002-04-08 at 13:45, Adam C Powell IV wrote:
I just received bug #141738 against petsc2.1.1-doc saying that links
from /usr/share/doc/petsc2.1.1-doc/include are going to
/lib/petscdir/2.1.1/include instead of /usr/lib/petscdir/2.1.1/include.
This is really odd, as I made them using dh_link and the links seem
correct (../../../.. should be /usr, right?), but indeed, they give
file not found errors when I try to inspect the files.
But what's *really* bizarre is:
ls .. [gives what I'd expect, /usr/share/doc/petsc2.1.1-doc contents]
ls ../.. [gives what I'd expect, /usr/share/doc contents]
ls ../../.. [gives what I'd expect, /usr/share contents]
ls ../../../.. gives not /usr, but root!
What's wrong with the system, such that this happens -- for both me and
the bug reporter? And why has this changed since I first made the
symlinks and tested them, and they worked?
I don't think this is a PETSc bug, but something deeper...
I can't reproduce this (but keep in mind that the .. entry in a
directory can theoretically point anywhere), but why don't you use
absolute link targets anyway? Looks like they would be shorter and less
error prone here.
What do you mean by "the .. entry in a directory can theoretically point
I think it means you should fsck your disk. Possibly the '..' in /usr/share
is pointing to the wrong directory (/ instead of /usr). What happens when
you 'cd ..' repeatedly out to root? Does it skip /usr?
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org