Access violation in boost filesystem 3 directory iterator

[Andreas Eckleder <a.eckleder@…>]

Whenever dir_itr_increment() reports an error (e.g. because an error code was returned by FindNextFile() on WIN32), directory_iterator_increment() will crash with an access violation when trying to throw a filesystem error.

The access violation is caused by an attempt to read the parent path string from it.m_imp immediately after calling it.m_imp.reset().

Please find a patch against boost 1.47.0 attached to this ticket. It fixes the issue without any side-effects by storing the parent path locally before calling it.m_imp.reset().

The issue is hard to reproduce as essentially a defective file-system is required to see its effect. However, I think it should be sufficiently clear from the patch what's going on. I ran across this when trying to read from an optical disc with a defective UDF file-system.

[Andreas Eckleder <a.eckleder@…>]

Patch fixing a potential access violation when trying to read defective directories / directories for which windows replies with an error code in FindNextFile().

[anonymous]

We ran into the same problem on OSX, when a directory was deleted while we were in the middle of iterating over it. Note that if you don't want to or can't change the source to Boost as per the patch above, simply passing in an error_code to directory_iterator::increment() will circumvent the bug, since the bad dereference is buried in the exception creation.

[anonymous]

I was wrong in my previous comment stating that there was a work-around without changing the source to Boost. There's a second bug that stops this from working. directory_iterator_construct() does not pass the error code to "increment", so even if an error code is passed into directory_iterator_construct(), when it gets into directory_iterator_increment() the error code will be lost and the exception will trigger.

[Beman Dawes]

I'm working Filesystem bugs right now. I'll work this one tomorrow or the next day.

Thanks,

--Beman

[Beman Dawes]

Both the original bug and the bug reported in comment 3 have been fixed.

Thanks for the reports and the patch!

--Beman