-
Notifications
You must be signed in to change notification settings - Fork 163
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
recursive_directory_iterator::increment fails assertion on corrupted file system #113
Comments
I haven't looked into the issue, but since you're working on it, did you consider what the C++ Standard says about it? Out of all possible solutions, I think the standard behavior would be more preferable. |
I have been able find some information about the other issue I reported (#112) in the draft of the standard (http://eel.is/c++draft/fs.class.rec.dir.itr#fs.rec.dir.itr.members) I have found this https://en.cppreference.com/w/cpp/filesystem/recursive_directory_iterator
This is not in the standard (at least in the draft I referred to) and I would find this behaviour unfortunate as it prevents the user to recover from the error in any way. |
Speaking of recovery, I have suggested two separate means of recovery in my PR #114. The differentiate between where the error occurs:
That means that the caller has little control over the recovery, because from the error_code it may not be evident which function failed, and thus they do not know if they should pop the current dir or not |
I think the current standard draft (N4820) is pretty clear on the intended behavior, and I think that behavior is sane. Specifically:
In the latter case the user can try to recover by manually calling Currently, there is no |
Upon reading the standard further it seems like this recovery is not allowed since the iterator is required to become equal to the end iterator on error. This follows from [fs.class.rec.dir.itr]/3 and [fs.class.directory.iterator]/3. |
See if the new option |
Hi, I took latest boost and filesystem submodule shows latest commit as f795041. I tried to check if the reproduction case mentioned in the above comments using fusepy is fixed. my-ThinkStation-P910:/myhome/mytest/boost/run_bugboost_171/from_site_113$ sudo -s usage: recursive_ls [path] In directory: "/myhome/mytest/boost/run_bugboost_171/from_site_113" "/myhome/mytest/boost/run_bugboost_171/from_site_113/recursive_ls.cpp" I built the recursive_ls using below : tried a version with -std=c++11 too but i get the same error. Is this issue fixed ? or am i missing something here? |
#113 #hi all,
becomes
and I remove the lines
Then I get the below error. usage: recursive_ls [path] In directory: "/myhome/mytest/boost/run_bugboost_171/from_site_113" "/myhome/mytest/boost/run_bugboost_171/from_site_113/recursive_ls.cpp" This issue is seen for our software that uses a boost version 1.65 too. |
The test code in the OP is incorrect because it dereferences the iterator in
I'm not a Python expert, but I think |
From operations.cpp
This invariant is not honored on corrupted filesystems, when a nested directory cannot be traversed fully.
An example of such "corrupted" filesystem is Apple implementation of quarantine on Mac OS X High Sierra and higher.
Steps to reproduce
Consider this program:
1. Real world example (Mac OS X High Sierra)
mount
command gives you something like:./recursive_ls /var/folders/ys/08961svn0qx6_1g9sg6j32sw0000gn/T/AppTranslocation/
(ids may vary, but the path must end with AppTranslocation)Output:
2. Artifical example (any linux or MAC with FUSE)
I have been able to reproduce this behaviour relatively closely with fusepy using the attached script.
memoryfs.py.txt
Python3 and pip is required
Output:
Analysis
In both cases, the opendir passes and readdir (or readdir_r) provides first few entries of the nested directory. After a few entries, readdir(_r) fails with an error.
The following condition gets activated:
which is then handled here:
it
equalsdirectory_iterator()
at the marked point, but we return too early to progress to another (possibly valid) directory.The text was updated successfully, but these errors were encountered: