GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
In the linux implementation of FindNextFile in linux/XFileUtils.cpp, FindNextFile will fail (return error) if the "next" file is a broken symbolic link. this has the (unintended I'm sure) effect of cutting directories entries short. If the first entry in directory is a broken symbolic link then FindFirstFile returns a handle, gives no indication of a problem and returns a partially populated LPWIN32_FIND_DATA structure.
Not being a Windows programmer and the documentation is not clear on what windows will do in this situation, someone need to check on it. If Windows has the same problem then this fix should probably be abandoned and a wrapper around FindNextFile and FindFirstFile created to do the same thing (but for all implementations presumably)
Note: this will also occur on insufficient permissions getting to a target of a symlink
Modify FindFirstFile and FindNextFile to always return a valid file o…
…r end of directory
FindFirstFile could have returned a partially populated WIN32_FIND_DATA structure
and FindNextFile could return false in the middle of a directory due to
a broken symlink.
clean up indenting from previous fix
It's a fact I'm an idiot - I checked against the wrong branch before I posted. I also misinterpreted why the stat - thinking it was to prevent having to check file validity later.