Re: mkdir inside symlink creates wrong directory with relative parent

[Oldřich Jedlička]

Hi Loïc,

Dne pondělí 13 Červen 2011 16:51:54 Loïc Le Loarer napsal(a):
> Hi,
> 
> This behavior is normal. The key here is the .. link in each directory, it
> always points to the parent directory.
> For example, in your situation, the ".." in z is x, and it cannot be
> something else.
> Even if you access to z using the path x/y/z which use the symbolic link,
> and then use ".." link, you go to x, not y.
> 
> You may have the impression that this is not true if you follow the same
> path using your shell, because the shell remember the fact that you use the
> symbolic link and don't really use the ".." link. When you do "cd .." in
> the shell, it just removes the last element between / in the current path.

Thanks for the explanation, that made the things much clearer. I understand 
now why the "test -d ../../something" doesn't work under the same conditions 
(because the directory really doesn't exist for the program).

But what you say is only part of the story. The script/program has the full 
knowledge od the current working directory and it can do the same trick with 
the path traversing - remove the ".." in the same way as the shell would do. 
This is normal when you canonicalize the path - remove the ".." from the path 
and do not try to dereference. The key is that getcwd() returns really the 
current working directory with symlinks unresolved - this is how the shell 
sees it too.

> I agree that it is a bit strange, but once you understand the fact that
> each directory contains a ".." link which points to one unique location
> and that when the path is interpreted by the kernel, it always follows
> those links, you understand how it works.

Yes. it is strange and the program has the full knowledge to do the right 
thing (TM) :-) So I think this can be fixed actually.

Best regards,
Oldrich.

> 
> Best regards
> Loïc
> 
> 2011/6/13 Oldřich Jedlička <address@hidden>
> 
> > Hi all,
> > 
> > I was trying to search for any description helping me understand in what
> > I see, but actually I didn't find any, so I'm here. I discovered it by
> > using automake-1.11, because it uses relative paths a lot. So my
> > simplified testcase is as follows:
> > 
> > Have a directory structure x/y and x/z/a. Have a symbolic link from x/y/z
> > that points to x/z.
> > 
> >   mkdir -p x/y
> >   mkdir -p x/z/a
> >   ln -s ../z x/y/z
> > 
> > Now go into x/y/z/a and try to create directory like that:
> >   cd x/y/z/a
> >   mkdir ../dir_xyz
> >   mkdir ../../dir_xy
> >   mkdir ../../../dir_x
> > 
> > I would expet that there would be a directory like this:
> >   x/dir_x
> >   x/y/dir_xy
> >   x/y/z/dir_xyz (x/z/dir_xyz)
> > 
> > But the result is completely different:
> >   dir_x
> >   x/dir_xy
> >   x/y/z/dir_xyz (x/z/dir_xyz)
> > 
> > So when you want to create a directory in the parent structure from
> > within the symbolic link, you will fail in doing so, because the
> > symbolic link would be resolved during walking through parents, so you
> > can get to completely different tree while creating your directory. It
> > looks like a bug, because it is nowhere documented to behave like that
> > (and the behaviour is strange by itself).
> > 
> > Verified on Debian 4.0/RedHat 5.4 with coreutils 5.97 and on Gentoo with
> > coreutils 8.12.
> > 
> > Regards,
> > Oldrich.