I need help, Is this a bug?

[kapitainsky]

Ok I think it is a bug IMO. Here how to reproduce it:

Please note that ？： are two characters:

EFBC9F ？ Ideographic question mark
EFBC9A ： Ideographic colon

Now in empty folder:

> echo a > test？：test.txt
> rclone copy . onedrive:test
> rclone lsf onedrive:test
test?:test.txt

lsf normalised ？：t to ?:

In another cmd window:

>rclone mount onedrive:test mountpoint
>dir /b mountpoint
testtest.txt

result for ?: are some gibberish characters (EF80BF EF80BA)

When I copy test？：test.txt test file to mount directly results are as follows:

rclone lsf onedrive:test
test?:test.txt

>dir /b mountpoint
test？：test.txt

lsf normalises ？：t to ?: but at the mount point I can see original correct characters.

The same issue has been reported also here:

Filename changed if using copy command

What is the problem you are having with rclone? Filename changed if using copy command. For example, I have one file named "test？：test.txt", if I use rclone copy command to copy to dropbox, the filename became "testtest.txt". In hex editor I found that "？：" is originally "ef bc 9f ef bc 9a", but became "ef 80 bf ef 80 ba" after copy to dropbox. This problem did not happen if I mounted and manually copy to dropbox using explorer. Run the command 'rclone version' and share the full output …

@ncw I think it is another case where VFS normalisation would help.

I used onedrive remote in my example but it behaves the same with other remotes.

It seems all works fine on Linux:

$ echo a > test？：test.txt
$ ls
test？：test.txt
$ rclone copy . onedrive:test
$ rclone lsf onedrive:test
test？：test.txt

lsf does not normalise anything

and all is ok on mount:

$ ls mountpoint
test？：test.txt