Possible bad behaviour in BFS with opendir

[nielx]

During my work on porting Rust I encounter the following situation, here's the pseudo code:

DIR *d = opendir("/path/to/folder/with/.a/files");
while ( d = readdir(d) ) {
    run("objcopy path_to_d");
}

During the objcopy the existing file is probably unlinked and re-added. It seems like BFS will be so nice to update the iterator to point to new files that are added, either at the unlinking or the file creation state. I am looking at ​BPlusTree::Insert which calls ​UpdateIterators().

The way the iterator is updated actually updates the iterator in such a way that the next one points to the currently updated file, thus creating an endless loop.

Now I am wondering whether this is incorrect behavior of the application, or whether it is an issue with BFS. The only hint I can find is in ​this Stackoverflow comment which comments about SUSv3 that it is unspecified whether it returns a file that has been added or removed since opendir() was called.

In a strict reading, bfs is just returning a file that has been added since the last run, so it is within defined behavior and the code I am testing is relying on undefined behavior.

If I am more generous I would say that the current behavior of BFS could be changed to have the next item on the iterator just point to the next vnode, and not 'rewind' to where a new vnode is added in front.

[nielx]

The bug has been fixed upstream, see ​https://github.com/alexcrichton/backtrace-rs/pull/96

Nonetheless I would like to invite an opinion from someone else whether or not we should change the behavior of BFS to support this on other platforms.

[korli]

It seems HFS is also "affected": ​https://support.apple.com/kb/TA21420?locale=en_US