-
-
Notifications
You must be signed in to change notification settings - Fork 870
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
Bug: Crash after synchronizing with core.time.TimeException: Invalid ISO Extended String #2810
Comments
@dploeger When building from source, please enable debugging:
To create a debug log output, please follow:
Thanks. |
@dploeger This is critically important to resolve this:
Once this is resolved, the reason for the crash can be understood and then fixed. Without this resolution, it is next to impossible to pinpoint the cause & fix. |
@dploeger
Augment the above with the instructions here on building your own Docker container: |
Meh. On a second run it works without a problem. I'll keep this in mind though. Thanks! |
No problem .. it would have been good to know what broke and where and why .... |
But now I see other problems in another run. I'll create the docker image and will use that internally. If another problem occurs, I can give you better information. |
@abraunegg Hm. --enable-debug still doesn't seem to work in the container: Or did I misunderstand you there? (I've build the image on the PR branch and pushed that to our internal registry to use it in the CI build) |
You need to recompile the actual 'client' .. by either building the entire client from scratch, or using the PR and build your own Docker container from the PR, which will do this step. When using the 'self built' container, the 'onedrive' binary will be built with |
I've checked out the PR and ran docker build. Isn't that what you mean with "self-built container"? |
Correct ... so now, if the client crashes, the internally built 'onedrive' binary will have the correct debugging enabled to capture what is going on. |
Ohhh. It's not a parameter to the entrypoint of the container? |
No it is not .. which is why you have to either:
|
Yeah, yeah. I got that. But I added --enable-debug to the parameter list and saw the error because I misunderstood you. Will remove it tomorrow and report any stack traces. Thanks for the support! |
@dploeger |
@dploeger Please can you pull this PR, and build a new Docker container from this PR:
When running the PR, your version should be: |
I've compiled the PR and will use that image from now on. Our pipeline runs for 4 hours though (one initial onedrive sync, generating the export and rsyncing it locally, second onedrive sync) so I can't provide faster insights I'm afraid. |
No problem - thanks for letting me know |
It now failed with this on the second sync:
|
Hope that helps |
That little part shows a 100% potentially different issue ....... |
Yes. The original TimeException doesn't seem to pop up again. |
We can update this issue to better reflect it or I can open another one |
Please raise a new bug report for tracking purposes |
This is in #2822 then. I'll close this bug then. |
Keep this one open for the moment until 2813 is also solved. |
* Add isValidUTCDateTime function to validate timestamp as received from OneDrive API to ensure it is valid * Use new function before attempting to call SysTime.fromISOExtString to ensure this call will be successful * If there is no timestamp in the JSON, set it to the system time * Add assertion when building an item from DB data * Add new function (isValidUTF8) to check UTF-8 validity of a string before timestamp regex check * In a --resync scenario, if the file hash is the same, use the online timestamp as source of truth * Ensure that the session URL data is a valid JSON response before use * Ensure a local time in UTC is being used if the JSON data has no date * Ensure the DB is opened in the most threadsafe manner possible * Add patch provided by @phlibi to add synchronized() around DB access methods * Align timestamp creation method with itemdb if element is missing
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Describe the bug
After synchronizing the data with --sync and vacuuming the database, the process crashes with this stack:
Operating System Details
Client Installation Method
From Distribution Package
OneDrive Account Type
Business | Office365
What is your OneDrive Application Version
onedrive v2.5.0
What is your OneDrive Application Configuration
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'
The onedrive sync folder is used for storing export data from one system and synced to a shared business folder.
Steps to reproduce the behaviour
Complete Verbose Log Output
Screenshots
No response
Other Log Information or Details
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: