Sync to OneDrive Personal lands file in LocalFileSystem but not in OneDrive

New rclone user. poured hours into trying to solve sync of one file the personal OneDrive. I run the command "rclone sync -i /home/john/Python_01/TempHumid piOneDrive". It appears to work (yah), but nothing shows up in OneDrive. The file does land in the local file system as mentioned in the verbose log ouput. I've tried config recreate and flooded my head from the documentation - banging my head on the wall.. please help me :slight_smile:

##Command: "rclone sync -i /home/john/Python_01/TempHumid piOneDrive"
##rclone version: "v1.59.1"
##Cloud storage system: OneDrive Personal

The command you were trying to run (eg rclone copy /tmp remote:tmp)

##Command: "rclone sync -i /home/john/Python_01/TempHumid piOneDrive"
type = onedrive
token = {<access_token>}
drive_id = <driveid>
drive_type = personal
2022/09/12 13:55:39 DEBUG : rclone: Version "v1.59.1" starting with parameters ["rclone" "sync" "-i" "/home/xxxx/Python_01/TempHumid" "piOneDrive" "--log-file=rcloelog.txt" "-vv"]
2022/09/12 13:55:39 DEBUG : Creating backend with remote "/home/xxxx/Python_01/TempHumid"
2022/09/12 13:55:39 DEBUG : Using config file from "/home/xxxx/.config/rclone/rclone.conf"
2022/09/12 13:55:39 DEBUG : Creating backend with remote "piOneDrive"
2022/09/12 13:55:39 DEBUG : fs cache: renaming cache item "piOneDrive" to be canonical "/home/xxxx/piOneDrive"
2022/09/12 13:55:39 DEBUG : TempHumid.csv: Sizes differ (src 41547 vs dst 41514)
2022/09/12 13:55:39 DEBUG : Local file system at /home/xxxx/piOneDrive: Waiting for checks to finish
2022/09/12 13:55:39 DEBUG : Local file system at /home/xxxx/piOneDrive: Waiting for transfers to finish
2022/09/12 13:55:41 DEBUG : TempHumid.csv: md5 = <32 char key> OK
2022/09/12 13:55:41 INFO  : TempHumid.csv: Copied (replaced existing)
2022/09/12 13:55:41 DEBUG : Waiting for deletions to finish
2022/09/12 13:55:41 NOTICE: 
Transferred:   	   40.573 KiB / 40.573 KiB, 100%, 0 B/s, ETA -
Checks:                 1 / 1, 100%
Transferred:            1 / 1, 100%
Elapsed time:         2.3s

2022/09/12 13:55:41 DEBUG : 3 go routines active

Hi John,

I wish rclone would recognize this situation and helpfully write:

WARNING: "piOneDrive" refers to a local folder, use "piOneDrive:" to refer to your remote with the same name. Note the ":" at the end of the name.

It is just so easy to miss and difficult to spot when you are caught in the situation :slightly_smiling_face:

1 Like

Perfect - thanks @Ole .. Great suggestion too! :slight_smile:

1 Like

If we can think of a way of doing this which doesn't annoy the more technical users then why not!

Perhaps make the warning if the source / destination path

  1. matches a remote with that name in the config
  2. the local directory/file does not exist

Does that strike the right balance @Ole ? Maybe we don't need the second rule?

I agree, it is very much a question of striking the right balance and having a simple rule.

How about something like:

If (strings.TrimSpace of) source/destination path matches a remote with that name in the config then
NOTIFY: "piOneDrive" refers to a local folder, use "piOneDrive:" to refer to your remote or "./piOneDrive" to hide this warning.

This eliminates the need for the second rule, which in reality would mean that the message only would be displayed once - unless we break backwards compatibility. I guess users in trouble may sometimes need several attempts to realize the mistake.

The check should also be performed when specifying remotes during configuration edit and configuration create/update. I have seen several forum issues where a missing : in an alias, crypt or union was the reason.

I assume leading/trailing spaces, : and / are illegal in remote names, otherwise we may need to think more carefully.

That sounds good.

Yes they are illegal. They need to match the regexp here

I think that check is straight forward enough...

It only needs to be done on the command line parsing which localises the place to rclone/cmd.go at master ยท rclone/rclone ยท GitHub in the 3 functions which call cache.Get.

I guess it could go in cache.Get but that will affect API and internal use.

That is actually an argument for putting it in cache.Get as that is what crypt will call with the remote.

I've done that (actually I put it in fs.NewFs which is what cache.Get calls to create a new backend from scratch) - can you give this a go and see what you think? I used your error message wording - thank you :slight_smile:

v1.60.0-beta.6441.e8a2f02a9.fix-no-colon on branch fix-no-colon (uploaded in 15-30 mins)

Thanks a lot, that sounds perfect. I will dig into the details and test it; and report back in a few days :slightly_smiling_face:

1 Like

I have read the code and tested some common and uncommon situations. All looks good and I really like the place you selected to trigger the warning, it works well :tada:

It is really pedantic and may not be worth changing, but I would move "DEBUG: Creating backend" above "NOTICE: yourRemote refers to a local folder" to make the debug log slightly more intuitive (in my eyes). Your call!

Just in case you don't know: There seems to be no betas for Windows or Linux (WSL/Ubuntu). Luckily I have learned how to quickly go build it myself :sweat_smile:

Thanks again!

@JonZeee We kind of hijacked your thread, hope you like the solution too.

Thank you for the idea - it is a great improvement!

I've done that.

Yes there was a problem with the build - now fixed.

I've merged this to master now which means it will be in the latest beta in 15-30 minutes and released in v1.60 :slight_smile:

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.