Opened 19 months ago

Last modified 19 months ago

#14126 new bug

Possible bad behaviour in BFS with opendir

Reported by: nielx Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (1)

comment:1 by nielx, 19 months ago

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.

Note: See TracTickets for help on using tickets.