RE: another manifestation of the .. bug
From: Corinna Vinschen [snip Cygwin non-POSIXness, which unless I'm delirious used to be a big deal to the Cygwin PTB] My point is that I'm happy to make Cygwin mostly POSIX compatible, but that implementing all crude border cases sometimes has more negative impact in other areas (one of them: speed), than it does help to make Cygwin useful (I hear cgf falling from his chair and rolling on the floor laughing in the background). That's why I like the way the OP (?) was going to go about it: add it, test it, and see what the actual impact on performance is. -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: another manifestation of the .. bug
On Oct 25 20:02, Eric Blake wrote: According to Corinna Vinschen on 10/25/2005 7:27 AM: And I really can't see how one testcase fails because Cygwin allows something which should fail according to POSIX qualifies for coreutils doesn't work out of the box on Cygwin. Does the coreutils testsuite not allow per-target XFAILs? Coreutils already won't pass the testsuite out of the box on cygwin due to other problems, where I am also maintaining cygwin-specific patches; my point was that if cygwin is ever fixed, it is one less workaround needing my maintainence. As for the coreutils testsuite, it does not have per-target XFAILs, but does have the ability to SKIP tests that are known to be invalid if various pre-screening tests show that a platform won't support the feature being tested. However, among all the platforms that coreutils is currently ported to, my understanding is that cygwin is the only platform that would need such an exemption to skip such tests due to the lack of POSIX semantics. My point is that I'm happy to make Cygwin mostly POSIX compatible, but that implementing all crude border cases sometimes has more negative impact in other areas (one of them: speed), than it does help to make Cygwin useful (I hear cgf falling from his chair and rolling on the floor laughing in the background). I'm also inclined to find the coreutils testsuite not overly useful. What exactly is the coreutils testsuite testing, coreutils or the underlying OS? Tests like the above are testing the OS, but that's not the job of the *coreutils* testsuite, that's the job of a POSIX compatibility testsuite. And, *if* the coreutils testsuite tests POSIX compatibility of the underlying OS, then what is that good for, if not to allow coreutils to workaround OS kinks in coreutils itself? After all, Cygwin is not a POSIX OS, it's just an emulation layer and we already have to do a lot of handstands using the standard Win32 API. It's ok to get hints where the POSIX compatibility isn't given, but I'm a bit annoyed right now, since you're just repeating the same point over and over again. It doesn't really help since it neither changes the fact that we already know the problem, nor does it change the fact that this is a definitive border case. Just out of curiosity, does CYGWIN=traverse help here? Btw, we're only two persons investing more than just a few minutes per week on Cygwin development and we only have so much time and energy. Hence you'll see SHTDI and PTC that often. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: another manifestation of the .. bug
On Oct 25 07:07, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The fact that cygwin incorrectly flattens /name/../ to / in pathname resolution without first resolving name is triggering a failure in a new test recently added to the coreutils testsuite. mkdir -p dir/.. test -d dir should always succeed when dir did not exist beforehand, but because cygwin is flattening stat(dir/..) into stat(.) rather than failing with the required ENOENT when dir does not yet exist, mkdir does not go on to create dir. I can work around this issue in coreutils by making mkdir - -p never use its initial stat() to short-circuit directory creation, but this will penalize normal usage because it will force calling mkdir for every name in the chain even when the ultimate directory already exists. I would much rather see a fix in cygwin so that coreutils would work out of the box in this case. Yes, I know, http://cygwin.com/acronyms/#SHTDI. And yes, I realize that such a change, if it is to ever happen, would be post-1.5.19, because of its potential impact. And I really can't see how one testcase fails because Cygwin allows something which should fail according to POSIX qualifies for coreutils doesn't work out of the box on Cygwin. Does the coreutils testsuite not allow per-target XFAILs? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: another manifestation of the .. bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 10/25/2005 7:27 AM: I would much rather see a fix in cygwin so that coreutils would work out of the box in this case. And I really can't see how one testcase fails because Cygwin allows something which should fail according to POSIX qualifies for coreutils doesn't work out of the box on Cygwin. Does the coreutils testsuite not allow per-target XFAILs? Coreutils already won't pass the testsuite out of the box on cygwin due to other problems, where I am also maintaining cygwin-specific patches; my point was that if cygwin is ever fixed, it is one less workaround needing my maintainence. As for the coreutils testsuite, it does not have per-target XFAILs, but does have the ability to SKIP tests that are known to be invalid if various pre-screening tests show that a platform won't support the feature being tested. However, among all the platforms that coreutils is currently ported to, my understanding is that cygwin is the only platform that would need such an exemption to skip such tests due to the lack of POSIX semantics. Also, it is possible to write a wrapper around stat() that will give POSIX semantics to .., using intermediate stat() and readlink() calls if the string contains /... Someday, I might attempt that task, to see what sort of impact POSIX semantics has when done at the application layer instead of the cygwin layer. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -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 iD8DBQFDXuOp84KuGfSFAYARAruMAJ9af2HA4inDT4sd3nFnNaTjOp7G4ACgzWnb may3d4cT0QydA5/aJuRR9X8= =lcMw -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
