You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
if read_from_container(&mut bufreader) is called sometime after the read_to_end() has been called on the same File, read_from_container() will always fail with error InvalidFormat("Unknown image format")
The mitigation is to place the read_from_container() before the read_to_end()and to try_clone() the File when passing its reader to the read_from_container().
I have only tested this on Windows 10. All versions 0.5.x and 0.4 seem to be affected. I have not tested on earlier versions of the library.
I am unsure if this behavior is known, but it should be documented as the operation fails otherwise silently aside from the aforementioned error which is incorrect; the data on disk is not corrupt, just the handle.
The text was updated successfully, but these errors were encountered:
I may be able to help you if your high-level goal is described.
Anyway, I will comment on the behavior.
If you have called read_to_end(), it is no surprise that read_from_container() will fail, because there is no data left.
Your "mitigation" does not make sense to me. Even if try_clone() is used, read_from_container() advances the underlying file pointer, so read_to_end() will not read what you expect, I guess.
if
read_from_container(&mut bufreader)
is called sometime after theread_to_end()
has been called on the sameFile
,read_from_container()
will always fail with errorInvalidFormat("Unknown image format")
The mitigation is to place the
read_from_container()
before theread_to_end()
and totry_clone()
theFile
when passing its reader to theread_from_container()
.I have only tested this on Windows 10. All versions 0.5.x and 0.4 seem to be affected. I have not tested on earlier versions of the library.
I am unsure if this behavior is known, but it should be documented as the operation fails otherwise silently aside from the aforementioned error which is incorrect; the data on disk is not corrupt, just the handle.
The text was updated successfully, but these errors were encountered: