id summary reporter owner description type status priority milestone component version severity resolution keywords cc 284 Inconsistent realpath() and stat() behavior dmik bird "The behavior of `realpath()` and `stat()` for paths containing path rewrite components is inconsistent. In particular, realpath() behaves as if such components were symlinks. However stat() doesn't recognize them as symlinks and will not report the S_IFLINK mode bit for them. For example, calling `reaplath(""/@unixroot/usr"")` will give you `C:/usr` (if `UNIXROOT` is set to `C:`). Given this, one might expect that ""/@unixroot"" is a symlink but apparently`stat(""/@unixroot"")`shows that this is a false assumption. This is not only a theoretical question. There is at least one program that is broken because of that: Python (at least the version hosted [http://trac.netlabs.org/rpm/browser/python/trunk here] and distributed in our RPM that supports symlinks and therefore makes a difference between `abspath` and `realpath`). Its `os.path.realpath` function is implemented not as a call to the libc `realpath()` function (as one might expect) but as a loop that walks over individual path components and calls `readlink` on those of them for which `islink` returns true. However `islink` (eventually backed up by `stat()`) returns false for paths like `/@unixroot`. First of all, it will return false because `stat()` itself will fail (see #283) but even if we imagine that that failure is fixed and `stat()` starts to work, it will simply return 0 in the `S_IFLINK` so that `islink` will still return false. Such a behavior of `islink` completely breaks `os.path.realpath` functionality for paths containing `/@unixroot` and similar. in such cases `realpath` will just return the same value as `os.path.abspath`. I discovered this problem when I was trying to fix the Python's [http://www.virtualenv.org/en/latest/ virtualenv] script (used to create directory-local python environments on the fly). Virtualenv does some path rebasing which fails on OS/2 for Python installed from RPM because it can't detect that `C:/usr` and `/@unixroot/usr` is the same thing. In virtualenv they originally do path comparison after calling `os.path.abspath`. Replacing that with `os.path.realpath` would let us fix the problem but we can't do that since `realpath` itself doesn't work." defect closed normal libc-0.6.6 libc 0.6.5 normal worksforme