-
-
Notifications
You must be signed in to change notification settings - Fork 864
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: Initial sync crashes with std.utf.UTFException: Invalid UTF-8 sequence #2829
Milestone
Comments
I close this as a duplicate of #2813. Although a different exception is reported, it appears that the actual cause (corruption of the mtime field in the |
Agreed |
abraunegg
added
Duplicate
This issue or pull request already exists
and removed
PR Provided - Needs Testing
Waiting on Response
Unable to reproduce
labels
Sep 22, 2024
abraunegg
added a commit
that referenced
this issue
Sep 26, 2024
* 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. |
Repository owner
locked as resolved and limited conversation to collaborators
Oct 4, 2024
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
This has been mentioned in #2813 already and might be related. It happened at the end of an initial sync of a Sharepoint folder. Re-running the exact same process (also with
--resync --resync-auth
) then completed normally.Operating System Details
Debian Bookworm (12) with backports enabled Linux phiptp 6.10.6+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.10.6-1~bpo12+1 (2024-08-26) x86_64 GNU/Linux
Client Installation Method
From Source
OneDrive Account Type
SharePoint
What is your OneDrive Application Version
v2.5.0-6-g280d369 (with PR 2816)
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
All local data is stored on ZFS
How do you use 'onedrive'
The folder is a company share, about 10 other people have access. Changes are rare, though. It is rather unlikely that a file was changed online during the run.
Steps to reproduce the behaviour
Although not currently tried, I could possibly remove all local files and state to trigger the same failure again. I can do this if requested, but since all this might be closely related to #2813, this will probably not provide much more insight.
Complete Verbose Log Output
Screenshots
No response
Other Log Information or Details
No response
Additional context
#2816
Client compiled from source with
--enable-debug
Total synchronized data is about 2.4GB in 5300 files
The text was updated successfully, but these errors were encountered: