fix(folderstatusmodel): 32 bit int overflow in current item progress fixed #8759
Conversation
barisbasar1209
requested review from
camilasan,
i2h3,
mgallien and
nilsding
as code owners
nilsding
left a comment
nilsding
left a comment
There was a problem hiding this comment.
LGTM, thanks for the contribution :)
…fixed Signed-off-by: Baris <[email protected]>
|
Artifact containing the AppImage: nextcloud-appimage-pr-8759.zip Digest: To test this change/fix you can download the above artifact file, unzip it, and run it. Please make sure to quit your existing Nextcloud app and backup your data. |
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
|
/backport to stable-3.17 |
4 participants
This PR address issue #8704 . Thanks for the reviews!
The problem: The syncing progress for files with at least 2GiB size shows overflown value in the accountsettings dialog, when resyncing.
Changes: Explicit typing to
qint64instead of usingautofor the relevant variable(s)Steps to reproduce:
.dbfile in the sync foldersettingsImages:
Before:
According log:
After:
According log:
I am aware that the project follows the
almost always autostyle, however using auto caused the variablecurItemProgressto be casted toint. The other variables that are declared alongsidecurItemProgresswere also casted tointeven though they were assigned return values of typeqint64in subsequent lines. Therefore I figured that making sure they are of typeqint64as well is safer (?).