What is the point of ls -f (or, why is this hanging?)

Question

I've got a directory with about 100,000 files in it. ls -f hangs for over a minute. I ran strace, and immediately started seeing getdents, so ls is clearly reading the directory. I also see a lot of calls to brk, so ls is clearly buffering things in memory. I wrote a simple program that calls readdir and outputs filenames, and it responds immediately. But ls -f does not provide output. What gives? I thought the whole point of -f is that it causes ls to do nothing more than readdir. Is there a portable, reliable way to list the contents of a directory? (Note, this is ls from gnu's coreutils on Linux.)

-EDIT-

There was an alias in place, but "/bin/ls -1f > /dev/null" takes 8 to 15 seconds, "/bin/ls -1fx > /dev/null" takes 4 to 11 seconds, but a simple program that just does readdir takes .011 seconds. What do I need to do to make gnu ls not suck?

Answer 1

The point of -f is to try and avoid the need to stat every file entry, and to avoid the need to read them all before any are displayed. It is a "meta" option that just disables other options.

So, yes, it should do what you expect. I can't answer why it isn't, but I would guess that you might have a shell alias or something else that inserts additional options to the command. That might reenable a feature than -f disables, and be considered "more specific", so take precedence.

Answer 2

An optimization was added in coreutils 7.0 (commit 8d974b00fbbc2025de63e1e6d54827648fefa1c4):

2008-08-01  Kamil Dudka  <[email protected]>
    ls -U1 now uses constant memory
    When printing one name per line and not sorting, ls now uses
    constant memory per directory, no matter how many files are in
    the directory.
    * ls.c (print_dir): Print each file name immediately, when possible.
    * NEWS: Mention the improvement.

The first explanation that comes to mind is that you're running an older version of coreutils. You need to upgrade.