/.../ in directory path
 

Building 'libproxy' and running 'make install' (Makefiles are generated by 'cmake') I've noticed lines like this:

- pay attention to "/.../".

/bin/sh accepts such paths, for example:

From the above it looks like

is equivalent to

.

Could someone please enlighten me where and and what to read on "/.../" - I don't remember seeing it before.

That does not work for me and I have never seen or heard of it during my red hat admin days. I tried several test shell scripts and none worked.

FWIW, I am seeing this on my SUSE-11.1 box.

Well, RTFMing (man 1p cd) I see:

- does it explain the behavior I observe ?

I do not see that text in my bash builtins man page. Where did you locate that information?

I missed your suse response. That would probably indicate a difference between the two families of Linux. Your excerpt does make sense; if it is from the man page for cd on your system then I would say there is your answer.

I think /mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/.../ must exist for that to work. Unless SuSE applies some very unsafe patches to its path resolution code.

In particular, cd /foo/.../../bar/ does not work on any of my systems (Debian and RHEL variants, no SuSE), when /foo/bar/ exists but /foo/.../ does not. (The cd(1) man page does have the same dot-dot handling description.)

It apparently exists and shows up as a regular directory:


.

Maybe it is created as a temporary hidden directory by 'make install', and later on files are moved from there to their final destinations ?

I yet to have to parse the quoted manpage piece.

I think you are spot on. Usually, the temporary install directory is something like .libs , or .$builddir . Since this package is configured via cmake .. (I think), perhaps the temporary install directory name is constructed by prepending a dot to the parameter to configuring cmake, yielding ... simply by accident?!

In any case, the quoted passage is incorrect in practice.

Path resolution does not simply apply s|/\+\([^/]+\)/\+\.\./\+|/|g (repeatedly) to the path to remove /../ components, because that would be a security risk.

In most cases, a path is assumed to be valid component-wise. That is, you should be able to trim a component off the end of the path, and end up in an existing, accessible directory, if the full path was accessible. If you allow nonexistent path components, that no longer applies.

The same rule applies when a component exists, but is inaccessible. Consider path /foo/bar/../baz/ where /foo/baz/ exists and is accessible, and /foo/bar/ also exists but is inaccessible. Because paths should be valid component-wise in practice, the original path should NOT be accessible.

I suspect this behaviour is implicitly standardized in POSIX; perhaps there is a passage that states that all components in a path must be accessible for the complete path to be accessible?

Unfortunately I'm too lazy to check. :p I first became aware of this almost a decade ago, when I was researching why Apache does so many directory lookups. (Partly due to this, partly due to .htaccess files and <Directory> directives.)

AFAIR it was an old novell netware feature.

@AnanthaP: You mean old Novell Netware accepted paths like foo\bar\..\baz as long as foo\baz existed even if foo\bar did not?

As it turns out, POSIX.1-2008 (IEEE Std 1003.1™-2008) realpath() function (which applications are supposed to but not required to use to canonicalize a path before doing any manipulations to it), does specify the explicit behaviour that I described earlier -- that foo/bar/../baz is accessible only if both foo/bar and foo/baz exist and are accessible:
In Linux, the kernel applies the same rule to all path resolution.

".." is a hard link to the parent directory, except in "/", which has ".." as a hard link to ".". While this might only be "simulated", processing the text of the pathname won't always be accurate. Suppose you had "/home/you/dir" -> "/". If you only went by the text, cd ~/dir/../home wouldn't work unless there was a "/home/you/home". Processing the text would also result in different behavior within C programs since presumably there isn't a kernel option to treat "..." specially. Also, I really wonder why there's a manpage for cd and why it could be different on another distro, since as far as I know cd can only work as a built-in (short of some procfs magic that I don't know about.) The manpage I have for cd is for a tcl built-in.
Kevin Barry

If you process each component separately, building upon the path component by component, it will be logically correct.

I don't understand that statement. POSIX.1-2008 realpath() and the Linux kernel path resolution handles that just fine by the text. ~/dir/../home is expanded by the shell to /home/you/dir/../home (~ is not special to the kernel nor realpath()), which is resolved in five steps:

1. /home
2. /home/you
3. /home/you/dir
   At this point, the resolved location is at / for both realpath() and the Linux kernel.
4. /home/you/dir/..
   The parent directory always exists, even at root. The resolved location stays at root for both realpath() and the Linux kernel.
5. /home/you/dir/../home
   Since the resolved location has a subdirectory home (as resolved already in the first step), this resolves to the exact same location as the first step.

I cannot find any contradiction between this behaviour and the POSIX.1-2008 text I quoted!

What? Like I said, every path component must exist and be accessible, for the path to exist and be accessible. This applies to both the Linux kernel, and POSIX.1-2008 realpath() function. (I have not bothered to check whether this is required by POSIX.1-2008 for all filesystems.)

Because the cd utility is in the POSIX standard. Regardless of how it is implemented, its functionality should be the same for users. This functionality is what the man page describes. (And as such, it is part of the POSIX man pages.)

(nevermind)

I'm genuinely puzzled. If I offended you or anyone else, I apologize; it was not my intention. I only wanted to clarify the issues.