Re: testsuite bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 PING According to Eric Blake on 11/15/2005 6:36 AM: The mv/leak-fd test is broken on cygwin (and possibly Mac, although I can't test that) due to case-insensitive file systems. Cygwin reports 'mkdir: cannot create directory `A': File exists' when `a' exists with a different spelling. This test is only run when RUN_EXPENSIVE_TESTS=yes. 2005-11-15 Eric Blake [EMAIL PROTECTED] * tests/mv/leak-fd: Work even on case-insensitive file system. - -- 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 Mozilla - http://enigmail.mozdev.org iD8DBQFEAwI684KuGfSFAYARAnToAJ9lZfrJ6i+b5E4a0GvVrLwqJWFC3QCgj0L7 jWs4mB158pD5puieXRwwG0k= =HPFd -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: root-dev-ino.c limitation
Jim Meyering [EMAIL PROTECTED] writes: So cygwin has are two root directories, / and //, with distinct dev/inode pairs? That would imply that there are two distinct trees. But, as I understand it, / is a subtree of //. If so, isn't // the real root, and can't the algorithm simply use the dev and ino for // on Cygwin, so that getcwd always returns a name that begins with //? This wouldn't remove the need for some //-specific stuff, but it would mean fewer changes to the code. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Documentation discrepancy for ls -f
I this still the right place to send bug-reports for GNU ls? Or should I use bug-coreutils instead? I'm using ls (GNU fileutils) 4.0. The info documentation has the following to say about -f: `-f' Primarily, like `-U'--do not sort; list the files in whatever order they are stored in the directory. But also enable `-a' (list all files) and disable `-l', `--color', and `-s' (if they were specified before the `-f'). while the message from ls --help says -f do not sort, enable -aU, disable -lst This differs with respect to the -t and --color options. That -f disables --color seems to match the implementation. I think it would also be helpful to say something about what -f is intended to be used for and why the option character 'f' (force) is selected for that. My best guess is that it is intended to make the operation as efficient as possible, disabling time consuming operation such as sorting the list and stat()ing all the entries, but I really don't know the background. Regards, /Niels ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls -i inefficiency
Eric Blake [EMAIL PROTECTED] writes: And here's the patch. As a nice side effect, it also optimized 'ls -L' to avoid stat() (after all, dereferencing makes no sense when all you need is file names, and no information from the dereference). Hmmm, won't that break the behavior on dangling symlinks? here's the coreutils 5.94 behavior: $ mkdir d $ cd d $ ln -s nowhere x $ ls -l total 0 lrwxrwxrwx 1 eggert eggert 7 Feb 26 01:17 x - nowhere $ ls -L ls: x: No such file or directory I haven't tried the patch, but from your description of it it sounds like the output of the last command would be x, which doesn't sound right to me. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
