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: >>> >>> cd /usr/share/doc/petsc2.1.1-doc/include >>> 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 > anywhere"?
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? -David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
