cygwin semantics of ..

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The cygwin maintainers are aware of a bug in their handling of .. in path
names that is inconsistent with POSIX, but are currently unwilling to fix
the bug because of the claimed speed impact to everything else related to
path name handling.  The bug is that when parsing any pathname, cygwin
shortens the substring foo/.. to . without first resolving foo.  One
symptom of this is that stat("foo/..") always succeeds, even if foo
doesn't exist (should fail with ENOENT), is a file (ENOTDIR), is
unsearchable (EACCES), or is a bad symlink (ELOOP, ENOENT).  Another
symptom is that even when readlink("foo") returns "bar/blah",
chdir("foo/..") leaves the current working directory in . rather than
changing it to ./bar.

This bug is very pervasive - fixing it in the application layer with
gnulib would require providing stubs for every single system call that
takes a path name, which would be even slower than a fix in cygwin.  But
leaving the bug in place means that various coreutils fail to comply with
POSIX semantics because of the underlying OS bugs.  For example, cygwin is
failing the new tests/mkdir/p-slashdot, because "mkdir -p d2/.." checks
whether stat("d2/..") is a directory to short circuit having to call
mkdir(2).  Since cygwin (wrongly) treats stat("d2/..") as stat("."),
mkdir(1) never creates d2.

For the test mentioned above, a workaround in mkdir-p.c can be written
that skips the optimization of an initial stat() on platforms where stat()
can wrongly succeed (is there any other platform out there with this bug,
or is it just cygwin); but it seems daunting to try and track down every
utility that might fail because of a .. semantics bug.  Is the best course
of action for coreutils to just update the testsuite to provide a filter
test that SKIPs any tests that rely on POSIX semantics of .. filename
resolution?

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDX4WO84KuGfSFAYARAugmAKCIEhATbDQtsDyRkJd2ASldIdPD/ACglnrP
iBbGcErOrdLP2piiWqbUzrc=
=RPth
-----END PGP SIGNATURE-----