abraunegg / onedrive

OneDrive Client for Linux
https://abraunegg.github.io
GNU General Public License v3.0
10.04k stars 859 forks source link

ERROR: The requested single directory to sync was not found on OneDrive #293

Closed mbkupfer closed 5 years ago

mbkupfer commented 5 years ago

Bug Report Details

Describe the bug I'm trying to synchronize a shared folder, but it is not syncing. I got the shared folder id using the --get-O365-drive-id switch and added that to by config folder as mentioned in the readme. Now when I do --synchronize nothing happens and when I chose single-directory, I'm getting an error that the directory was not found.

It appears the onedrive cli is using a different directory since the drive id that comes up when I use --verbose is not the one that comes up when I use the get id switch.

Application and Operating System Details:

Complete Verbose Log Output A clear and full log of the problem when running the application in the following manner (ie, not in monitor mode):

mkupfer@ubuntu:~/onedrive$ onedrive --synchronize --verbose --single-directory 'Analyst'
Loading config ...
Using Config Dir: /home/mkupfer/.config/onedrive
Initializing the OneDrive API ...
Opening the item database ...
All operations will be performed in: /home/mkupfer/OneDrive
Initializing the Synchronization Engine ...
Account Type: business
Default Drive ID: b!g....gqi
Default Root ID: 01...Z
Remaining Free Space: 1093606954799
Fetching details for OneDrive Root
OneDrive Root exists in the database
Syncing changes from this selected path: Analyst
Syncing changes from selected OneDrive path ...
ERROR: The requested single directory to sync was not found on OneDrive
Uploading differences of Analyst
Uploading new items of Analyst
Skipping item - path excluded: Analyst
ERROR: The requested single directory to sync was not found on OneDrive

Additional context Verification that folder does in fact exist:

$ ls ~/OneDrive/
Analyst

Config folder

$ cat ~/.config/onedrive/config 
dirve_id = "b!9...OwH" # note that this is different then what appears in verbose

Using display config that was implemented in pull/292

$ onedrive --display-config
Config path                         = /home/mkupfer/.config/onedrive
Config file found in config path    = true
Config option 'sync_dir'            = /home/mkupfer/OneDrive
Config option 'skip_file'           = ~*
Config option 'skip_symlinks'       = false
Config option 'monitor_interval'    = 45
Config option 'log_dir'             = /var/log/onedrive/
Selective sync configured           = true

Bug Report Checklist

abraunegg commented 5 years ago

@mbkupfer As discussed via email, the issue stems from the implementation of supporting O365 Shared Libraries.

The --single-directory option, when originally written, there was no support for O365 Shared Libraries, which is why when it is attempted to use to just sync a single path as per your use case, it (--single-directory) fails as it does not exist.

Likewise, when you use --create-directory it creates this against your account, rather than the configured drive_id

Note: In your cat ~/.config/onedrive/config above, you have incorrectly spelt dirve_id - is this a 'github' typo or is this actually the file contents (allowing for your redaction of your actual Shared Library id). The option should read:

drive_id = "b!9...OwH"

Also - onedrive --display-config should display the drive_id if configured .. will have to add that in

abraunegg commented 5 years ago

Also - onedrive --display-config should display the drive_id if configured .. will have to add that in

Updated PR #292 to include drive_id if configured

abraunegg commented 5 years ago

@mbkupfer I have been doing some local testing, and cannot replicate this issue:

./onedrive --confdir '~/odconfig/' --synchronize --verbose --single-directory 2
Loading config ...
Using Config Dir: /home/alex/odconfig/
Initializing the OneDrive API ...
Opening the item database ...
All operations will be performed in: /home/alex/OneDriveALT
Initializing the Synchronization Engine ...
Account Type: documentLibrary
Default Drive ID: <redacted>
Default Root ID: <redacted>
Remaining Free Space: 27487788881294
Fetching details for OneDrive Root
OneDrive Root exists in the database
Syncing changes from this selected path: 2
Syncing changes from selected OneDrive path ...
Getting path details from OneDrive ...
Applying changes of Path ID: <redacted>
Downloading file 2/Document.docx ... done.
Uploading differences of 2
Processing 2
The directory has not changed
Processing Document.docx
The file has not changed
Uploading new items of 2
Getting path details from OneDrive ...
Applying changes of Path ID: <redacted>

Can you revalidate your configuration if possible?

mbkupfer commented 5 years ago

@abraunegg

You were correct in noticing the typo, I fixed it and it is working well. I still need to play around to get comfortable. I noticed something strange though: my root folder (the one that I used to get the drive_id) was actually syncing to a sub-folder. It was very weird. I believe this can be better explained with illustration:

Imagine I got my drive_id using onedrive --get-O365-drive-id 'drive_root'. When I synchronize, it is synchronizing with Folder_B. Any idea what's going on here?

drive_root/ ├── Folder_A └── Folder_B

mbkupfer commented 5 years ago

@abraunegg Also, --synchronize with no options does not synchronize all folders. It simply does nothing if no there are no local folders. Not sure if this is related to my previous issue with a sub-folder being the one that is synchronized or a bug. Let me know if I can provide more information in regards to that.

abraunegg commented 5 years ago

@abraunegg

You were correct in noticing the typo, I fixed it and it is working well. I still need to play around to get comfortable. I noticed something strange though: my root folder (the one that I used to get the drive_id) was actually syncing to a sub-folder. It was very weird. I believe this can be better explained with illustration:

Imagine I got my drive_id using onedrive --get-O365-drive-id 'drive_root'. When I synchronize, it is synchronizing with Folder_B. Any idea what's going on here?

drive_root/ ├── Folder_A └── Folder_B

Unsure. Potentially it could be due to having the typo, thus the items database is screwed up. Can you perform a --resync and see if that clears up the situation?

My understanding here is:

onedrive --synchronize --verbose --single-directory 'Analyst'

Analyst is a top level folder in the 'Research' Shared Library

Locally, you should have (I am assuming default local path here):

~/OneDrive/Analyst

When you run the above command, the Analyst folder should 'sync' from the 'Research' Shared Library to the local ~/OneDrive/Analyst as this is what my tests above do without issue.

abraunegg commented 5 years ago

@abraunegg Also, --synchronize with no options does not synchronize all folders. It simply does nothing if no there are no local folders. Not sure if this is related to my previous issue with a sub-folder being the one that is synchronized or a bug. Let me know if I can provide more information in regards to that.

It is probably related, as - if you take away the --single-directory 'Analyst' portion, it should just sync the entire tree, using your configured drive_id:

onedrive --synchronize --verbose

Example:

./onedrive --confdir '~/odconfig/' --synchronize --verbose 
Loading config ...
Using Config Dir: /home/alex/odconfig/
Initializing the OneDrive API ...
Opening the item database ...
All operations will be performed in: /home/alex/OneDriveALT
Initializing the Synchronization Engine ...
Account Type: documentLibrary
Default Drive ID: <redacted>
Default Root ID: <redacted>
Remaining Free Space: 1099511169598
Fetching details for OneDrive Root
OneDrive Root exists in the database
Syncing changes from OneDrive ...
Applying changes of Path ID: <redacted>
Uploading differences of .
Processing root
The directory has not changed
Processing 2
The directory has not changed
Processing Document.docx
The file has not changed
Uploading new items of .
OneDrive Client requested to create remote path: ./1
The requested directory to create was not found on OneDrive - creating remote directory: ./1
Successfully created the remote directory ./1 on OneDrive
Uploading file ./1/1.txt ...
Uploading 100% |oooooooooooooooooooooooooooooooooooooooo|   ETA   --:--:--:                                                                                                             
 done.
Remaining free space: 1099511169569
Applying changes of Path ID: <redacted>
mbkupfer commented 5 years ago

thus the items database is screwed up

Is this the sqlite db in my confdir? What happens when I delete it, which I tried as a troubleshoot? It seemed to just get recreated last time I did it.

Unsure. Potentially it could be due to having the typo, thus the items database is screwed up. Can you perform a --resync and see if that clears up the situation?

Yes! That did it. Really interesting, I think I'm starting to wrap my head around how this works. Feel free to close the issue if you feel appropriate.

p.s I have a directory called ~/.config/onedrived/. Is this an artifact of skillion's branch or is this part of this new one? I want to know if it is safe to remove.

abraunegg commented 5 years ago

Is this the sqlite db in my confdir? What happens when I delete it, which I tried as a troubleshoot? It seemed to just get recreated last time I did it.

In your confdir you should have the following:

-rw-rw-r--.  1 alex alex   347 Dec 20 06:02 config
-rw-r--r--.  1 alex alex 15360 Dec 20 05:58 items.sqlite3
-rw-rw-r--.  1 alex alex   847 Dec 20 05:58 refresh_token

The items.sqlite3 file is the local cache file that tracks what is in sync / what is not in sync & will be re-created every time when the application is run, or if you call --resync

p.s I have a directory called ~/.config/onedrived/. Is this an artifact of skillion's branch or is this part of this new one? I want to know if it is safe to remove.

This was probably installed via some other package or application that you have installed for 'onedrive'. I would check your packages that you have installed and:

Is that directory safe to remove - most likely.

abraunegg commented 5 years ago

Closing as resolved - configuration

lock[bot] commented 5 years ago

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.