Downloading certain .md files fails for unknown reason

[TunedRockets]

I've been trying to set up onedrive to work with obsidian, I've done the whole

force_session_upload = "true"
delay_inotify_processing = "true"

thing, but the problem I'm now getting is that, when I've modified files in obsidian on my other (windows) computer, and try to sync onedrive on my laptop (using this client) i get the message:

[2025-Dec-14 15:12:52.1482964] Failed items to download to/from Microsoft OneDrive: 1
[2025-Dec-14 15:12:52.1483067] Failed to download: Documents/[redacted]/Stochastic lecture notes.md

Then the file appears to become invisible to the onedrive client, not getting downloaded on subsequent syncs. It only reappears after a --resync. It also does not appear to happen to every file, but this file specifically it seems to always happen to (though not only this file). Given that i only have the vague "failed to download" I'm at odds on how to continue troubleshooting this. does anyone have any idea what could be causing it?

[abraunegg]

@TunedRockets
Can we start with some basics?

• output of curl --version
• output of onedrive --version

Download issues are usually linked to those.

When you run the application with --verbose what else is displayed relating to why it failed to download?

Please follow the Basic Troubleshooting Steps as outlined here:

https://github.com/abraunegg/onedrive?tab=readme-ov-file#basic-troubleshooting-steps

[TunedRockets]

Curl is version 8.17.0, and onedrive is 2.5.9. I'll see if i can recreate it with some other files, but unless --verbose creates something more than what's put in onedrive.log then that's all the errors I get, here's that part of the log with the things around it:

[2025-Dec-14 15:12:52.1418814] Finished processing /delta JSON response from the OneDrive API
[2025-Dec-14 15:12:52.1428162] Processing 5 applicable JSON items received from Microsoft OneDrive
[2025-Dec-14 15:12:52.1428387] Processing OneDrive JSON item batch [1/1] to ensure consistent local state
[2025-Dec-14 15:12:52.1482607] 
[2025-Dec-14 15:12:52.1482964] Failed items to download to/from Microsoft OneDrive: 1
[2025-Dec-14 15:12:52.1483067] Failed to download: Documents/[redacted]/Stochastic lecture notes.md
[2025-Dec-14 15:12:52.1485400] 
[2025-Dec-14 15:12:52.1485581] Sync with Microsoft OneDrive has completed, however there are items that failed to sync.
[2025-Dec-14 15:12:52.1485718] To fix any download failures you may need to perform a --resync to ensure this system is correctly synced with your Microsoft OneDrive Account

P.s:
As is typical, when i tried to replicate it it worked perfectly (for no reason i can see), even remembering the "forgotten file". So I guess thanks for scaring it straight 😅. (let's hope it stays that way)

[abraunegg]

@TunedRockets
Please always use/add --verbose as this always gives mich more insight as to what the client is doing and is always critical in understanding what is going on.

[TunedRockets]

I do use --verbose (or rather -v) when running it, but it runs in a background script, hence why i referred to the log instead. Is there any difference between using enable_logging = "true" and reading the log compared to, say, running onedrive -vs >> my_log.txt?

[abraunegg]

With verbose enabled - the reason why the download failed should be displayed - could be:

• unable to write
• size difference between what was to be downloaded vs what was downloades
• checksum issue

All of those elements are verbose log entries.

If you are not seeing this, please ensure you are activating verbose and the application is acting in that manner

There should be near zero difference between enable logging or console redirection when using verbose output - and it should be really clear if this is being activated correctly.

onedrive -vs

I have not personally tested like this ...

Separate thse out to be sure please

[TunedRockets]

I checked and verbose was definitely enabled, I just can't find any other error than the one I sent. It seems to work now but I'll keep a lookout if it happens again.

[abraunegg]

Let me look into the code .. there also could be a logging gap here.

If this is the case, please raise a bug report.

[abraunegg]

I have reviewed and there is a logging gap. Please raise a bug report for tracking.