Google Doc filenames containing single quote broken with 1.43

[lnxsrt]

What is the problem you are having with rclone?

Remote Google Doc filenames containing single quotes are no longer are directly syncable. This worked correctly with v1.42. Indirectly syncing (syncing the entire directory instead of an individual file) works fine in v1.43.1.

What is your rclone version (eg output from rclone -V)

rclone v1.43.1
- os/arch: linux/arm64
- go version: go1.11

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

Linux 4.17.14-1-ARCH #1 SMP Fri Aug 10 20:50:01 MDT 2018 aarch64 GNU/Linux

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)

rclone sync "remote:/Temp/test's.docx" test/

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

2018/09/17 21:18:47 DEBUG : rclone: Version "v1.43.1" starting with parameters ["rclone" "sync" "-vv" "remote:/Temp/test's.docx" "test/"]
2018/09/17 21:18:47 DEBUG : Using config file from "~/.config/rclone/rclone.conf"
2018/09/17 21:18:48 ERROR : : error reading source directory: directory not found
2018/09/17 21:18:48 INFO  : Local file system at /test: Waiting for checks to finish
2018/09/17 21:18:48 INFO  : Local file system at /test: Waiting for transfers to finish
2018/09/17 21:18:48 ERROR : Local file system at /test: not deleting files as there were IO errors
2018/09/17 21:18:48 ERROR : Local file system at /test: not deleting directories as there were IO errors
2018/09/17 21:18:48 ERROR : Attempt 1/3 failed with 1 errors and: not deleting files as there were IO errors
2018/09/17 21:18:48 ERROR : : error reading source directory: directory not found
2018/09/17 21:18:48 INFO  : Local file system at /test: Waiting for checks to finish
2018/09/17 21:18:48 INFO  : Local file system at /test: Waiting for transfers to finish
2018/09/17 21:18:48 ERROR : Local file system at /test: not deleting files as there were IO errors
2018/09/17 21:18:48 ERROR : Local file system at /test: not deleting directories as there were IO errors
2018/09/17 21:18:48 ERROR : Attempt 2/3 failed with 1 errors and: not deleting files as there were IO errors
2018/09/17 21:18:48 ERROR : : error reading source directory: directory not found
2018/09/17 21:18:48 INFO  : Local file system at /test: Waiting for checks to finish
2018/09/17 21:18:48 INFO  : Local file system at /test: Waiting for transfers to finish
2018/09/17 21:18:48 ERROR : Local file system at /test: not deleting files as there were IO errors
2018/09/17 21:18:48 ERROR : Local file system at /test: not deleting directories as there were IO errors
2018/09/17 21:18:48 ERROR : Attempt 3/3 failed with 1 errors and: not deleting files as there were IO errors
2018/09/17 21:18:48 Failed to sync: not deleting files as there were IO errors

[ncw]

I can replicate this.

Git bisect points the finger at this commit by me

commit e42edc8
Author: Nick Craig-Wood
Date: Mon May 7 18:13:17 2018 +0100

copy, move: Copy single files directly, don't use --files-from work-around

Before this change rclone would inefficiently and confusingly read all
the files in the source directory when copy or moving a single file.
This caused confusion for the users to see log messages about files
which weren't part of the sync.

After the change the copy and move commands use the new infrastructure
made for the copyto and moveto command for single file copy and move.

Which means that NewObject isn't finding these files (previous to this commit we weren't using NewObject we were using a directory scan).

So I suspect that commit uncovered a bug that has been there for a long time!

Interesting that the error is "error reading source directory: directory not found"

@B4dM4n you were last having a look at that bit of code - what is your opinion?

[B4dM4n]

I found the issue and it's my fault. Two variables got mixed up.

The PR will fix this.

[ncw]

Please find the fix in

https://beta.rclone.org/v1.43-090-g13823a77-beta/ (uploaded in 15-30 mins)

• thanks @B4dM4n