If you name a file on gdrive with characters that are not allowed in NTFS filenames, a rclone mount of the cloud drive with vfs caching set to full will fail to interact in any way other than listing the file in the directory due to vfs being unable to create the backing file in the cache
Run the command 'rclone version' and share the full output of the command.
rclone v1.57.0
os/version: Microsoft Windows 10 Pro 2009 (64 bit)
os/kernel: 10.0.22000.675 (x86_64)
os/type: windows
os/arch: amd64
go/version: go1.17.2
go/linking: dynamic
go/tags: cmount
Which cloud storage system are you using? (eg Google Drive)
Google Drive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
Sounds like it might be the same root issue, yeah. VFS not translating the path or file name in any way causing NTFS to refuse the path creation due to the illegal characters. Could the same translation that rclone does for uploading files to a cloud drive with illegal characters be applied to VFS possibly?
Presumably the files don't work if you turn VFS caching off either?
I think there are two problems here
the vfs cache needs to translate characters
rclone mount needs to translate characters
The entire VFS should be doing translations for rclone mount to make the file names legal. However something like rclone serve webdav might or might not need the transations depending on exactly where you are using it. So the VFS probably needs an optional file name translation to translate files into that used by the local backend. This would need to be forced on for rclone mount.
However the VFS mount caching always needs filename translation.
The files copy correctly if vfs caching is disabled, so it is seemingly just the fact that the VFS cant write to the cache file that is stopping the operation with it enabled
If the files can't be written to the NTFS disk (in the VFS cache) then how can you copy them to an NTFS disk? I'm probably mis-understanding something!
So, did some more digging. Seemingly non-vfs is translating the name on file operation, wide colons are fine as they are permitted in NTFS filenames, but standard colons are translated into a dot. This one to be precise, , if you can even see it as it just shows up as the unicode char not found box in Chrome for me
Unicode codepoint f03a is what the normal colon gets translated to, which just appears as a dot, while Unicode codepoint ff1a, which is the wide colon is passed directly through
Ah, I see, that is WinFSP doing the name translation - see here for details:
So it looks like WinFSP is working around 2. for us (maybe not in an ideal way), so 1. here is more urgent.
Part 1. also isn't too tricky - maybe you could open a new issue on Github about just that and I'll have a go at fixing. Or you could have a go and I'll talk you through it?
Made a issue, If I have time soon and its not done by you or someone else first, ill see if I can figure it out or ill ask you for help, but my job just ramped up to mega since summer started so I probably wont have much time to try to help outside of information and testing