Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[cmp] propagate decompression errors from bled #1040

Closed
wants to merge 1 commit into from

Conversation

wjt
Copy link
Contributor

@wjt wjt commented Oct 12, 2017

If, for example, you have a truncated gz-compressed file and try to write it to disk, bled_uncompress_with_handles() will return an error. Previously, this was not reported back to the user -- there's no indication of any problem. If they're lucky, booting the partially-written disk will fail in an obvious way, but better to report an error sooner, even if we cannot give details.

(This is inspired by a similar change in our fork. This branch is untested until Visual Studio 2017 finishes downloading!)

If, for example, you have a truncated gz-compressed file and try to
write it to disk, bled_uncompress_with_handles() will return an error.
Previously, this was not reported back to the user -- there's no
indication of any problem. If they're lucky, booting the
partially-written disk will fail in an obvious way, but better to report
an error sooner, even if we cannot give details.
@wjt
Copy link
Contributor Author

wjt commented Oct 12, 2017

I have, however, tested the same change applied to our fork with our UI.

@pbatard
Copy link
Owner

pbatard commented Oct 13, 2017

Very good point. Rufus should definitely report errors from Bled. The pull request has been applied — many thanks for this!

@pbatard pbatard closed this in 8863180 Oct 13, 2017
@wjt wjt deleted the propagate-bled-error branch October 13, 2017 10:33
wjt added a commit to endlessm/rufus that referenced this pull request Oct 13, 2017
Compared to our previous version of this change:

* handle negative return values from bled_uncompress_with_handles besides
  -1, since at least the unxz decompressor can return
* log the error code returned
* return FALSE from WriteDrive on error (even though no call site checks
  it)
* use ERROR_WRITE_FAULT rather than ERROR_NO_MEDIA_IN_DRIVE, which seems
  closer to the likely truth

Submitted upstream: pbatard#1040
@lock
Copy link

lock bot commented Apr 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.

@lock lock bot locked and limited conversation to collaborators Apr 6, 2019
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants