Bug report, rclone-v1.49.5.xxx

What is the problem you are having with rclone?

rclone-v1.49.5-windows-amd64 ~ rclone-v1.49.5-213-gb63e9bef-beta-windows-amd64

What is your rclone version (output from rclone version)

rclone-v1.49.4-windows-amd64

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Windows10

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)

A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)

2019-10-14_140656

Can you tell me more please? What exactly is the problem?

I think this is probably caused by rclone's new escaping system for characters which can't be represented.

Can you cut and paste some logs please so I can examine the unicode characters?

Thanks

1.4
1.5
1.5.xxx
It is folder situation when each worked.

Can you post the debug logs?

I see the problem.

Let's say I have a folder with files like this on drive

image

If I use rclone 1.49.5 I get this. Note how rclone cannot access a file with an actual in.

$ rclone-v1.49.5 lsf  drive:test/dir
file with / slash.txt
file with / unicode slash.txt
file.txt

This is fixed with rclone beta. I get this:

$ rclone lsf  drive:test/dir
file with ‛/ unicode slash.txt
file with / slash.txt
file.txt

That is what is causing your problem.

It is only a display problem it shouldn't affect how rclone works.

You can rename

file with ‛/ unicode slash.txt

to

file with / unicode slash.txt

with rclone and the file on google drive will change from

file with / unicode slash.txt

to

file with / unicode slash.txt

So this is only a problem for people that have / in their file names on google which hopefully isn't many.

Does the above error correct in the Stabilized version?

This is the new behavior and will become standard in v1.50

I use a lot of Unicode, including '/'.
Because '/' cannot be used for folder or file name.
I can't figure out why I am getting a Unicode error since rclone 1.5.xxx. Are you saying that this is not a bug right now? Will there be no Unicode support in the future?

If you have in your file names then from 1.50 rclone will escape that as ‛/. That is transparent and shouldn't affect anything.

However / can be used in names on Google drive. Rclone escapes these into (the unicode equivalent). This means existing names with need to be escaped as ‛/.

I'm sorry for the inconvenience. The old scheme in 1.49 was also doing escaping but it didn't deal properly with all the cases.

Unicode is 100% supported, you'll just notice a bit of extra escaping if you use in your file names.

Thank you for your kind reply every time.
In the meantime, I didn't understand the answer. '/ This display is endurable. The problem is not only the display, but certain programs cannot read the contents of the marked folder. (Explorer reads well.) Specific programs include qBittorrent, tixati, etc.

I'm not sure why you did that, but there's no problem at 1.49, and no problem at 1.50. The problem starts with the 1.5xxx beta.

Why can't those programs read the contents of the marked folder? What is the error?

Is the problem because the file / directory names changed?

Or is it something else?

Thank you for your explanations

Thanks for the video - you can take it down now.

What has happened is that the file names for file with in have changed.

This works fine in explorer. The other programs (qBittorrent, tixati) probably need to refresh the folder. Can you reload or refresh them so they use the new name?

Thanks for the reply. You are the most passionate and kind of developer I have ever seen.

I tested rclone-v1.50.0-003.
Not resolved yet You still see this "" / "in the explorer, and the same in tixati. The folder cannot be read because of the name.

:blush:

Why can't the folder be read?

Is it because the name has changed?

Or because of something else?

I can only say guess words.

I guess ...
Torrent clients seem to require a real name.

I'm not sure how to naming rclone 1.5,
Isn't it junk link method?
Is it a similar concept?

I wonder why you changed to this rename method.

I could put an option in to disable the / -> translation.

This will cause problems if you have / in your files on google drive.

Do you want me to do that?

Yes, if you put that option, fortunately I can use the latest version.

But ... I'm afraid that naming before v1.4.5 is better. (Translation is optional)

For people who speak a language other than English, I think this is a very important issue.

Good

It seems to be only the character that is the problem. Is that correct?

The option I would put in would affect only.

Do you think that will work?

Yes ~ / It seems to affect the characters. I did not find any problems with other characters.

If it is necessary to treat the / character as' /, I suggest that the direction of putting it as an option is correct.

OK I'll do that! Can you please make a new issue on github with the suggestion in and a link to this forum page and I'll see to it in a day or two.