search

vitalif / grive2

Google Drive client with support for new Drive REST API and partial sync
http://yourcmc.ru/wiki/Grive2
GNU General Public License v2.0
1.52k stars 140 forks source link

Stuck at "Reading remote server file list" on first use #348 #195

Open Demetrio92 opened 6 years ago

Demetrio92 commented 6 years ago

https://github.com/Grive/grive/issues/348

user@laptop_model:~/$ grive -v
grive version 0.5.1-dev Jan 10 2018 11:20:45
Demetrio92 commented 6 years ago

To reproduce (on my machine, ubuntu 16.04.3) 

user@laptop_model:~/main_folder$ grive -a
-----------------------
Please go to this URL and get an authentication code:

[LONG_URL]

-----------------------
Please input the authentication code here: 
[SUPER_SECRET_CODE]
Reading local directories
Reading remote server file list

Stuck here. My size of gdrive is 11G

yashsaxena commented 6 years ago

@Demetrio92 It happened the same with me...It might be the case that you have a lot to be synced so it is taking time try this user@laptop_model:~/$ grive -d -d gives you debug level information - so as long as you see post/get requests being exchanged b/w your machine & remote server - its okay. Its just the amount of files that is taking time...

Its stuck only if you see no post/get traffic

yashsaxena commented 6 years ago

@Demetrio92 Additionally try syncing only one folder at a time user@laptop_model:~/$ grive -v -s FOLDER_NAME

aspiers commented 6 years ago

I have the same problem, but even when I selected a subdirectory via -s it's still clearly iterating my whole drive. Given that I back up phones, tablets, photos etc. to Drive, I probably have tens of thousands of files outside the selected subdirectory. So most likely this will take so long that grive2 is totally unusable for me :-( This sounds like quite a major flaw with -s.

aspiers commented 6 years ago

Ah, this is also mentioned in #188.

aspiers commented 6 years ago

@aspiers commented on 1 Jul 2018, 01:26 BST:

I have the same problem, but even when I selected a subdirectory via -s it's still clearly iterating my whole drive. Given that I back up phones, tablets, photos etc. to Drive, I probably have tens of thousands of files outside the selected subdirectory. So most likely this will take so long that grive2 is totally unusable for me :-( This sounds like quite a major flaw with -s.

And here's the proof:

https://github.com/vitalif/grive2/blob/84c57c121e03b070f80e1d8fd66749eead7a4d9e/libgrive/src/base/State.cc#L65

aspiers commented 6 years ago

@aspiers commented on 1 Jul 2018, 01:26 BST:

I have the same problem, but even when I selected a subdirectory via -s it's still clearly iterating my whole drive. Given that I back up phones, tablets, photos etc. to Drive, I probably have tens of thousands of files outside the selected subdirectory. So most likely this will take so long that grive2 is totally unusable for me :-(

Happily I was too pessimistic, and it only took a few minutes to run. So I guess the ignore pattern is managing to skip huge directories.

nodatahere commented 6 years ago

I think I saw a commit somewhere in the repo's network that fixes this issue, but I've not been able to find it.