Question: It appears that nio's `.list` returns a stream which when consumed, holds on to one file descriptor per file iterated, until `.close` is called on the entire stream. This means that data directories with upwards of 1,000 files can easily brush against common `ulimit` values. The overall effect of this file descriptor accumulation, further exacerbates when dealing with nested traversals.

What might be an alternative way to iterate over the files of large directories, other than going down to spawning calls to the OS file list command? It would be cool if iterating the files of a large directory, a file descriptor would be maintained only per the currently iterated file, as implied by proper stream semantics.

Edit:

`list` returns a java Stream of `java.nio.file.Path` Which api call would be used for closing each item on the stream once it's been processed, rather than only when the entire stream is being closed, for leaner iteration? In scala, this can be easily fiddled using the api wrapper from better-files, leading from [here](https://github.com/pathikrit/better-files/blob/1c6f0f05d2aa3e16ddb06c0b275d0da9372fa7b0/core/src/main/scala/better/files/File.scala#L236).

Answer: 
If that happens why not to use old school java.io.File?

```
File folder = new File(pathToFolder);
String[] files = folder.list();

```

tested with `lsof` and it looks like no of the listed files is open. You can convert the array to a list or stream afterwards. Unless the directory is too large or remote, then I would try to blame Path objects and garbage-collect or somehow destroy them.
You may use the Apache FileUtils library, which use the old 
java.io.File.listFiles function internaly :

```
Iterator<File> it = FileUtils.iterateFiles(folder, null, true);
while (it.hasNext())
{
   File fileEntry = (File) it.next();
}

```