Copy from OneDrive local folder incomplete

[Notme]

Hello

As the title says, I have a local folder, synchronized with OneDrive for Business. I am using the "Files-On-Demand" setting, which only downloads files when needed.
When I open the local OneDrive folder in TC and hit F5 (cm_Copy i believe) it gets copied to the other panel - well, almost copied. Often there is a part of file missing a couple of kB or just a few bytes. That happens if the file isn't downloaded yet. After it is, it gets copied completely.
Sometimes it also happens that the copied file size is a few bytes larger, than the source.

I gave this a good search, but the closest topic I found was OneDrive on demand sync
viewtopic.php?f=3&t=48132

I've only observed this with .XLS(X) and .DOC files.
I haven't had the same problem when opening the files from the OneDrive local folder directly.

[ghisler(Author)]

This is unfortunately outside of my control: I just call a Windows function to copy the file (CopyFileExW). The OneDrive redirector then downloads the file, and CopyFileExW copies it. TC itself doesn't do anything during that time except for showing the progress, so there must be a bug in the redirector somewhere.

What you can try is using the Explorer copy method: Ctrl+C, Tab, Ctrl+V. You can enable that for F5 too if it helps.

[Usher]

Often there is a part of file missing a couple of kB or just a few bytes. That happens if the file isn't downloaded yet. After it is, it gets copied completely.

You shouldn't call it "download", it works like copy from a network drive. The function responsible for copying reserves space on disk on the copying start. It always reserves size rounded down to full clusters so it's a little bis smaller than the whole full size. For example, you have file which has 100'651'353 bytes in size, and the function reserves 100'597'760 bytes (exactly 24'560 clusters).
You can see similar behavior when copying large files with TC on local drives. Observe timestamps (modification date) - reserved space has current timestamp while fully copied file should have the same timestamp as the source.

Sometimes it also happens that the copied file size is a few bytes larger, than the source.

I don't think it's rounding up to full clusters, but you haven't provided any file sizes.
I observed similar behavior for misconfigured or somehow buggy web servers or proxies (or other software working as proxy, for example antivirus filters) - files may be passed with HTML wrapper or with empty characters (0x00 or just spaces) added. There may be also another case for text files - the may have converted EOLs on-the-fly while copying (for example when using FTP with text mode set for text tiles).

Just guessing…

[Notme]

Thanks for the replies.

I am not interested in going 'very' much into details, like cluster sizes, reserved space, etc. But since I just now got a larger target than the source, here are some sizes.
source: 24585 B
target: 24589 B
Bytewise file comparison shows 4 extra empty chars (0x00) in the end of the target.

This file was copied (not downloaded ) along with 5 others, which all went well.

Anyway, Ctrl+C, Ctrl+V seems to be working OK, so it's not he greatest problem on Earth.

[Usher]

Maybe you need to exclude TC process from scanning in Windows Defender (or other antivirus)?
See this topic:
Comparing files is slow because of Microsoft Defender Antivirus