Eric Blake wrote: > In working with PATH problems, I noticed these bugs in the testsuite. The > only > bad PATH in misc/sort-compress was leftover from when sort attempted to use > gzip unconditionally. But since sort now requires --compress, rather than > assuming gzip is present, that clause of the test was not covering anything > useful any more; the patch changes the test from fail to pass. > > rm/fail-eperm changes from fail to skip when run as an admin user (since > windows is rather generous with delete rights beyond what the POSIX > permissions > would imply); it will take a bit longer to actually run the test as a non- > admin, but I'm assuming it will now pass in that case. > > misc/pwd-long was interesting. On cygwin 1.5, it is impossible to create a > directory with more than 256 bytes in the absolute name. This fix changes > from > a fail to a skip. On cygwin 1.7, the name length limitation was lifted, so my > first round of edits improved from outright failure (inability to find > cygwin1.dll required by pwd) to 50% chance of failure (some runs passed, but > some failed due to problems converting $actual to a relative name). After > quite some time debugging, I finally discovered what appears to be the > culprit - > a bug in cygwin's perl. It looks like perl was built for 32-bit math, but > cygwin's ino_t is 64-bit. Depending on what inode was created for the > temporary dir, $i==$ino sometimes passes, but sometimes ran into overflow > issues in converting the stat result from a string into a number, such that > the > numeric comparison failed. Using eq always succeeds, thus working around that > problem and making the test reliably pass on cygwin 1.7. > > OK to apply?
Sounds good. I'll review and test tomorrow. You're welcome to push sooner.
