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 " 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
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).
I am running coreutlls on Windows, not linux... so strace does not work
there.
The November 10, 1999 version 3.16 of coreutils "ls" command is
lightning fast on Windows (and on the large directory) but unfortunately
stops at 32K files. The newer version of "ls" built for Windows has the
prob
It's probably something inside the kernel (e.g., filesystem code).
What does the shell command 'strace -o /tmp/tr -s 128 -T ls -U -1
dirname | wc' say? You can see which system calls are taking the most
time by then running 'sort -t"<" -k2n /tmp/tr'. On my platform (Fedora
29 x86-64 ext4, an older
My machine has 64GB of ram, 6 core 3.5ghz processor and fast disks.
The directory in question has 57,600 files in it with a total size of
about 47gb.
On a freshly booted machine (nothing cached), "dir /on dirname | wc"
takes about 6 seconds. The second time it takes about 2 seconds.
On a fresh
On 4/29/2019 4:36 AM, David Ellenberger wrote:
> Dear maintainers
>
> I understand that admins have become accustomed to see 4096 in directories
> as it's consistent with the ls command and the technicality behind it.
>
---
Except that it isn't 4096 on all file systems. For empty
directorie
