Subject: bug#35531: problem with ls in coreutils

From: Viktors Berstis <[email-masked]>
Date: Fri, 3 May 2019 08:56:35 -0700

I don't think the problem has anything to do with sorting or -U1.  When ls is taking over 5 minutes for something that should run in a couple of seconds, the task manager shows that it is using nearly no CPU.... it is doing a lot of  "other I/O".

It doesn't look like the build you referenced is designed to be compileable for Windows.  Is there one that is?  Thanks.

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v7.5~49

- Viktors Berstis

Kamil Dudka wrote:

On Friday, May 3, 2019 5:43:20 AM CEST Viktors Berstis wrote:

I downloaded it from
https://sourceforge.net/projects/gnuwin32/files/coreutils/5.3.0/coreutils-5.
3.0.exe/download The help said "Report bugs to <[email-masked]>"
which is what I did. The build is so old that I suspect none of the
original players are around. Do you know of a windows binary or windows
source that is newer
anywhere? Thanks.

- Viktors Berstis

`ls -U1` will not run significantly faster than `ls` on powerful hardware.
The key difference is that `ls -U1` prints the results continuously as the
list of files is read from file system whereas `ls` will be silent until
the complete list is read. You need to use a new enough version of coreutils
for this to work properly. This optimisation was introduced in coreutils-7.5:

https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v7.0~113
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=v7.5~49

Kamil

Paul Eggert wrote:

On 5/2/19 5:41 PM, Viktors Berstis wrote:

The newer version of "ls" built for Windows has the problem.

Ah, then you'll have to talk to whoever built that version, which is not
me (and generally speaking they don't hang out on this mailing list).