Its immediately clear from the log that my attempt to not truncate the file didn't work 
I just tested it locally on Linux and it does appear to work....
So either it is something to do with your system (eg Windows) or could you have run the wrong binary? Your log doesn't have the very start where rclone prints its version so I can't check.
I've been attempting to replicate this locally. I've written a python program which simulates what windows does to the exe (based on the above).
Can either of you try this on the exe file in the mount and report back its output.
"""
Read parts out of the executable like windows does
"""
import sys
import time
if len(sys.argv) < 2:
print(f"Syntax {sys.argv} <file>")
raise SystemExit(1)
file_name = sys.argv[1]
t0 = time.time()
def dt():
return time.time() - t0
def readAt(f, size, off):
"""
Read size bytes from offset
"""
f.seek(off)
bs = f.read(size)
assert len(bs) == size
print(f"{dt():.6f} {file_name}: read {size:6} bytes at {off:6}")
f = open(file_name, "rb")
readAt(f, 4096, 0)
readAt(f, 16384, 840192)
readAt(f, 15360, 872960)
f.close()
f = open(file_name, "rb")
readAt(f, 4096, 0)
f.close()
f = open(file_name, "rb")
readAt(f, 32768, 0)
readAt(f, 32768, 839680)
readAt(f, 32768, 880640)
readAt(f, 32768, 0)
f.close()
f = open(file_name, "rb")
readAt(f, 32768, 0)
f.close()
f = open(file_name, "rb")
readAt(f, 32768, 0)
f.close()
f = open(file_name, "rb")
readAt(f, 4096, 0)
readAt(f, 16384, 840192)
readAt(f, 15360, 872960)
readAt(f, 4096, 0)
readAt(f, 16384, 840192)
readAt(f, 15360, 872960)
f.close()
Run it like this
$ python3 test_bin.py /mnt/tmp/bin.exe
0.001172 /mnt/tmp/bin.exe: read 4096 bytes at 0
0.001438 /mnt/tmp/bin.exe: read 16384 bytes at 840192
0.001769 /mnt/tmp/bin.exe: read 15360 bytes at 872960
0.002156 /mnt/tmp/bin.exe: read 4096 bytes at 0
0.002891 /mnt/tmp/bin.exe: read 32768 bytes at 0
0.003285 /mnt/tmp/bin.exe: read 32768 bytes at 839680
0.003428 /mnt/tmp/bin.exe: read 32768 bytes at 880640
0.003438 /mnt/tmp/bin.exe: read 32768 bytes at 0
0.003915 /mnt/tmp/bin.exe: read 32768 bytes at 0
0.004429 /mnt/tmp/bin.exe: read 32768 bytes at 0
0.004951 /mnt/tmp/bin.exe: read 4096 bytes at 0
0.005035 /mnt/tmp/bin.exe: read 16384 bytes at 840192
0.005164 /mnt/tmp/bin.exe: read 15360 bytes at 872960
0.005169 /mnt/tmp/bin.exe: read 4096 bytes at 0
0.005175 /mnt/tmp/bin.exe: read 16384 bytes at 840192
0.005181 /mnt/tmp/bin.exe: read 15360 bytes at 872960
And give it the path to the file.
The timestamps are how long the program has been running so we should see delays in there.
I haven't managed to reproduce this on Linux yet.
I made a new binary to try
v1.61.0-beta.6556.7eefa3428.fix-vfs-pause on branch fix-vfs-pause (uploaded in 15-30 mins)
This has extra debugging in it to show how long the truncated bits and pieces take. There are two operations, setting the file sparse and truncating it and with microsecond log we should see what is going on.
11:30:56.253333 DEBUG : 20M: _truncateToCurrentSize: need truncate - current size -1 new size 0
11:30:56.253335 DEBUG : 20M: _truncate: starting
11:30:56.253368 DEBUG : 20M: _truncate: start SetSparse
11:30:56.253371 DEBUG : 20M: _truncate: end SetSparse
11:30:56.253372 DEBUG : 20M: vfs cache: truncate to size=0
11:30:56.253374 DEBUG : 20M: _truncate: start Truncate
11:30:56.253388 DEBUG : 20M: _truncate: end Truncate
You can drop the --dump headers now - I think we've eliminated that.
Could it be disk bound? Any way of checking that?
My