-
Notifications
You must be signed in to change notification settings - Fork 30
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
Panic when running ntfs_shell::dir in home directory #10
Comments
This is probably the same issue and root-case that i stumbled upon, so i'm hijacking this issue with my analysis :) I found that this stems from a subnode VCN value of 0 inside a
The issue, afaict, is that the seek implementation for |
You're right, I just tested #11 and it does fix it the issue for me too. |
@leofidus @vthib Thanks a lot for your bug report and the analysis!
The design above gets problematic as soon as I want to return the absolute filesystem byte position of the current seek position. I only have a valid value for that if Now I have multiple other parts of the code, which urgently need to know the absolute filesystem byte position, and can't just deal with an ntfs/src/attribute_value/non_resident.rs Lines 48 to 52 in be1fc19
This mitigation fails though when you seek to
I need some more time to think this through and come up with a definite solution that works in all cases.
This may take some time. In any case, thanks for uncovering this bug and the related #9! |
I think #9 is a good example of how the error types should have position as an
which is completely reasonable (why would there be a data run if there is no data). From a cursory look changing the error types to an option and passing the option along as long as possible would also get rid of a lot of unwraps. It wouldn't solve #9 or #10 on its own, but I think it's a reasonable starting point. |
`NtfsPosition` is built around an `Option<NonZeroU64>`. This allows functions to gracefully return that they currently don't have a valid position, without being larger than an `u64` in memory. The change allows us to get rid of lots of possibly panicking `unwrap` calls. Recent commits have shown that there are more valid cases where the `data_position` functions could return `None`. Examples are non-resident attributes without any Data Runs or non-resident attributes beginning with a sparse Data Run. Maybe even zero-length Data Runs are possible. In any of these cases, we mustn't unwrap the return value of `data_position`. Almost always, these positions are only used to give better error messages and assist with debugging anyway. Hence, their calculation should never cause a panic. Thanks to @leofidus for the inspiration in #10
I don't know what's causing it or how to narrow it down, but I'm happy to run it with a couple println statements or something if you can give me a clue where to start
The text was updated successfully, but these errors were encountered: