Consistently getting "corrupted on transfer: sizes differ" syncing to an SMB share

[yichi_yang]

@asdffdsa

if the file size CHANGES during copy operation, then rclone let's you know.
imho, that is the correct behavior.

I think I'm experiencing the same issue as you did here:

`rclone copy t:\ --include=filename` does NOT work, but `rclone copy t:\filename` works

never. in fact, the source is write-protected, i cannot edit it, cannot delete it [image] well, the source dir is a vss snapshot ;wink happens to many dozens, hundreds of files. easily reproduced. i tested this over a couple of days, different vss snapshots, different dirs, different rclone flags, etc.. not just me, happens to others fellow rcloners as posted about in the forum. fastcopy, fc, fchash, 7zip, certutil, double commander, windows explorer, dos cmd, powershell, all, always cop…

Not sure if I've made my point clear, but my source is also write-protected (in a VSS snapshot) and I don't expect their size to change. I'm pretty confident it's the same issue you reported in the above post.

I agree with @ncw that it probably has something to do with VSS (rclone somehow fails to get the correct file size because of VSS related issues and incorrectly reports those files as changing in size).

`rclone copy t:\ --include=filename` does NOT work, but `rclone copy t:\filename` works

Hmm ok, so this is something to do with VSS. If you do this do you get the correct file size or not? rclone lsl t:\ --include=/filename So when rclone read the file via the directory listing it was the correct size 1147752 - I'd expect the lsl above to give the correct size 1147752 in that case. It is when rclone read the size through an open file descriptor that the size is wrong, so this comment Is probably correct. os.Lstat good, os.File.Stat bad. That's definitely a bug, but in wh…

I do see @ncw asking for a minimal reproduction example - I can take a stab at that over the weekend.