4 ms·
If you haven't prepared for this eventuality then odds are you're going to run out of inodes first. And it's probably not useful to just dump all those filename
by Y_Y 5y ago
If you haven't prepared for this eventuality then odds are you're going to run out of inodes first. And it's probably not useful to just dump all those filenames to your terminal. And don't even say you were piping the output of `ls` to something else!
Anyway the coreutils shouldn't have arbitrary limits like this, at least if they do then the limits should be so high that you have to be really trying hard in order to reach them.
- cmeacham98 5y agoThere isn't actually an arbitrary limit, it's just that glibc's readdir() implementation is really really slow with millions of files according to the article. Presumably if you waited awhile `ls` would eventually get the whole list.
- matheusmoreira 5y agoThe glibc functions are just bad wrappers for the real system calls which no doubt work much more efficiently. I fully expected to find the system call solution in the article and was not disappointed.
- p_l 5y agoit's not readdir() that is slow - it's the way ls needs to load the whole directory into memory then do a bunch of things on it (sorting, calculating column sizes, etc), and depending on what you have in your defaults or passed options it might also try to stat() every of those files first.