Unable to overwrite 0 byte files from seemingly failed transfers

[Dude_Box]

There are no errors in the log but it happens transparently to Windows. No matter what I try to overwrite those 0 byte files, Windows and all programs I tried throw me an 'Access denied' or that I'm lacking permissions.

Already ran the mount with -o Username=User but no dice.
Running rclone as a service with nssm.
Here are the flags:

--config "C:\Users\User\.config\rclone\rclone.conf"
mount drive:\ R:
--log-file=rclone.log
--log-level INFO
-P
--exclude *\desktop.ini
--ignore-case
--drive-acknowledge-abuse
--volname GDrive
--rc
--rc-no-auth
--rc-web-gui
--rc-addr ##############
--rc-user test
--rc-pass test
-o Username=User
--cache-dir D:\rclone_cache
--vfs-cache-mode full
--vfs-cache-poll-interval 20m
--vfs-cache-max-age 4h
--vfs-cache-max-size 512G
--vfs-read-chunk-size 128M
--vfs-read-ahead 1G
--vfs-case-insensitive
--attr-timeout 8700h
--dir-cache-time 8760h
--poll-interval 30s
--multi-thread-streams 8
--transfers 4
--timeout 30s
--stats 5m
--buffer-size 16M
--no-modtime

[Dude_Box]

It seems this was caused by a bug, which was fixed on v1.54.

[Krakkan]

I still have this issue with Elgiganten Cloud (Jottacloud) with 1.54 (with latest winfsp). Using nssm.
No matter the configuration of the mount when copying files to a mount it can randomly create a 0 byte version of that file before copying starts then asks to overwrite it witch always fails.
Nothing shows up in the log files. It happens rarely and seemingly random sometimes weeks/month without it happening.
I delete the 0 byte file and recopy its the only thing i can do.

[Dude_Box]

That's the same situation I was in but since I updated to v1.54, it hasn't happened but, like you said, I've been using for some months now and it was a very sporadic thing.
I created this thread because dozens of files were being accused of being "stale" and deleted in the last few days. It was driving me crazy.
Then I updated rclone and the stale files were working fine, even the deleted ones were recovered. Most likely was a cache error.