-
Notifications
You must be signed in to change notification settings - Fork 275
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
ngclient: simplify storing a downloaded file #1799
ngclient: simplify storing a downloaded file #1799
Conversation
Pull Request Test Coverage Report for Build 1756649124
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks correct to me.
To make it more obvious you could mention in the commit message that this means we no longer do fsync. It believe that's fine in our use case but could be worth mentioning.
ab1aabd
to
fec5bf1
Compare
fec5bf1
to
fda0b1b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is correct, left a comment about the docstring
tuf/ngclient/updater.py
Outdated
@@ -218,8 +217,7 @@ def download_target( | |||
ValueError: Invalid arguments | |||
DownloadError: Download of the target file failed in some way | |||
RepositoryError: Downloaded target failed to be verified in some way | |||
exceptions.StorageError: Downloaded target could not be written | |||
to disk | |||
OSError: Cannot open "filepath" for writing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
strictly speaking there are quite a few reasons for OSError here, not just failing to open file (like not enough space as an example).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the message.
Do you think that now is better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure there was anything wrong with the original message? Alternatively "Failed to write target to file" could work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understood you had some reservations about it.
I updated the pr with your suggestion.
fda0b1b
to
8c4b171
Compare
8c4b171
to
88e9afe
Compare
Replace the usage of securesystemslib.util.persist_temp_file() with shutil.copyfileobj() as file system abstraction is not used in the client. This way we prevent securesystemslib.exception.StorageError from leaking through client API calls. Note: with those changes we are no longer do fsync. Signed-off-by: Martin Vrachev <mvrachev@vmware.com>
88e9afe
to
3fa0668
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks.
If another maintainer wants to chime in on the issue of not using persist_temp_file()
(and as a result, not fsyncing) that would be welcome: I've tried to think the failure scenarios through and this seems like the simplest code that does what we want.
Fixes #1761
Description of the changes being introduced by the pull request:
Replace the usage of
securesystemslib.util.persist_temp_file()
withshutil.copyfileobj()
as file system abstraction is not used in theclient.
This way we prevent
securesystemslib.exception.StorageError
fromleaking through client API calls.
Note: with those changes, we are no longer do fsync.
Signed-off-by: Martin Vrachev mvrachev@vmware.com
Please verify and check that the pull request fulfills the following
requirements: