abraunegg
commented
4 months ago @gitbls Thanks for raising these questions and testing RC1.
I built 2.5.0-rc1 on Debian 12 X64. Did
onedrive --sync --upload-only --dry-run --enable-logging
Firstly, when enabling logging I would always also include --verbose so you have a more accurate log of what is actually occurring. Without using --verbose output is really limited and is not going to be informative or helpful.
which took almost 4 hours to complete. (Using the current released version without --dry-run takes 15-20 minutes).
This will be 100% correct for a first run with v2.5.0 as there has been lots that has changed, including the DB schema which is not backwards compatible. This is essentially also the same as doing a --resync. Once v2.5.0 has been fully synced that first time, the process should be much faster than v2.4.x series.
You can redo this test with either dropping back to v2.4.25 (the DB schema will be incompatible, and perform a full scan) - to which you can then also determine the time difference between v2.5.0 and v2.4.25 for that --resync scenario.
IMPORTANT POINT: Because you are also using --dry-run ... your resulting sync state will also never be saved - which will make it difficult to then accurately determine the performance benefit of v2.5.0 as the resulting DB is not saved.
So this is not a bug or issue.
It also reported:
New items to upload to OneDrive: 81278which surprised me given that a sync was done a few hours prior and everything in onedrive cloud was up to date.
This is 100% correct because it has no record of these as being stored online at this point in time - because of the DB Schema change which is the same as doing a --resync ... and if you do a --resync with v2.4.25 you will have a similar exercise occur, but you wont know exactly what is being checked as needed to be uploaded .....
So this is not a bug or issue, but is one of the application output changes.
There were several of these errors:
Skipping uploading this item as a new file, will upload as a modified file (online file already exists): ./Backups/Pictures/RSA/2002Picnic/P9220027.JPG The local item is out-of-sync with OneDrive, renaming to preserve existing file and prevent local data loss: ./Backups/Pictures/RSA/2002Picnic/P9220027.JPG -> ./Backups/Pictures/RSA/2002Picnic/P9220027-mondo.JPG
OK .. this essentially means that the file already exists online. Due to you not using --verbose you are missing why the backup action is being taken - is the size different, is the hash different, is the timestamp different .....
If the size or hash (meaning the content of the file online does not match) is different that is when the local file is backed up so that you can then determine what is the correct file ... maybe you edited or cropped the file locally ... who knows ... but a difference was detected between online and local and action was taken to preserve your data.
So this is not a bug or issue.
To assist with your understanding all of the above 3 items, please read the Client Architecture Documentation and potentially change your usage to include / add --verbose
and a couple of this error:
ERROR: Microsoft OneDrive API returned an error with the following message: Error Message: HTTP request returned status code 502 () Error Reason: Error Code: UnknownError Error Timestamp: 2024-03-16T17:51:34 API Request ID: d1639031-705e-48c3-a866-c0cae6b51e98
This is a genuine error, but without any context as to where this is occurring or why.
A HTTP Status Code 502 is a standard HTTP response status code that indicates a gateway or proxy server received an invalid response from an upstream server. In the context of calling an API, this usually means that the OneDrive service is acting as a gateway or proxy and attempted to forward your request to another server but received a bad response from that server. A 502 error is usually indicative of issues on the server side or with the network, not with the API requests the 'onedrive' application is making.
To dig into this actual error, a full debug log would be required to dig into where and how this is being generated and what the 'onedrive' application did when this was encountered - was the request retried correctly .. ??
Please read: https://github.com/abraunegg/onedrive/wiki/Generate-debug-log-for-support to generate a debug log.
Once you have got this log available, please generate password protected archive and email the debug logfile through.
If you are concerned about data sensitivity, please read:
gitbls
Describe the bug
I built 2.5.0-rc1 on Debian 12 X64. Did
which took almost 4 hours to complete. (Using the current released version without
--dry-runtakes 15-20 minutes).It also reported:
which surprised me given that a sync was done a few hours prior and everything in onedrive cloud was up to date.
There were several of these errors:
and a couple of this error:
Operating System Details
Client Installation Method
From Source
OneDrive Account Type
Personal
What is your OneDrive Application Version
2.5.0-rc1
What is your OneDrive Application Configuration
What is your 'curl' version
Where is your 'sync_dir' located
Local
What are all your system 'mount points'
What are all your local file system partition types
How do you use 'onedrive'
onedrive is run in a systemd timer-enabled script nightly. The script does the command:
Steps to reproduce the behaviour
I'm sure I can easily reproduce it here by switching to the new verison of onedrive with the above command.
Complete Verbose Log Output
I could provide this by doing another run, but there is a huge amount of personal information that I would need to redact (directory names, file names, etc).
Please let me know if you need this after you've reviewed the above information.
Screenshots
No response
Other Log Information or Details
No response
Additional context
No response