--force=upload требует предварительной синхронизации? about cloudcross HOT 16 CLOSED

Добрый день. Начну по порядку:

Пишет Reading remote files. Ждал 10 минут, плюнул - выключил.

OneDrive возвращает данные о файлах в облаке в формате JSON. Размер описания одного файла примерно 2 килобайта. Таким образом, если в облаке ~250Gb небольших файлов, то время на получение этих данных может быть весьма значительным.

Режим --force просто отключает сравнение файлов для поиска более новых и считает более новыми либо локальные, либо удаленные файлы, в зависимости от download/upload. В остальном работа программы не отличается от режима синхронизации, то есть данные об удаленных файлах будут также предварительно получены из облака.

На всякий случай занес все папки в .include
ls > .include

Если сделать так, то файл .include будет заполнен строками вида
file_1
file_2
file_3
В то время, как правильно должно быть
/file_1
/file_2
/file_3

и выполнил
ccross --provider onedrive --dry-run --path backup --use-include --force=upload

Здесь вы неверно использовали параметр --path - отсюда и проблемы с видимостью ключа. Этот параметр нужен в случае если программа запускается не для текущей папки. То есть если вы находитесь в папке /home/user, а хотите синхронизировать папку /home/user/backup, то в этом случае надо указать параметр --path /home/user/backup

Резюмируя - изначально вы все делали правильно, просто не дождались пока данные о файлах в облаке скачаются в клиент. Так же, вы правильно решили использовать параметр --force upload, это позволит избежать скачивания всего облака на диск.
Если вы дадите больше данных о структуре вашей локальной ФС и структуре файлов в облаке и укажете что вы хотите залить в облако и куда, я помогу вам правильно заполнить файл .include

Также, я был бы благодарен, если бы вы написали о результатах - мне интересно, как поведет себя программа в таких условиях, когда столь много файлов в облаке. Не будет ли сегфолтов, уходов в своп и прочее.

from cloudcross.

Добрый вечер, спасибо за ответ.

У меня в облаке есть папка backup и в ней подпапки /backup/Sub-1 - /backup/Sub-M. И на локальной машине в ~ папка backup, а в ней подпапки ~/backup/Sub-M+1 - ~/backup/Sub-N. В каждой папке куча файлов. По факту мне нужно просто залить содержимое локального backup в облачный (и освободить место на локальной машине), но onedrive не умеет подгружать уже существующую папку через web интерфейс, и не умеет multiupload папок. И, похоже, выходом является подгружать backup в backup-1, а потом перемещать его содержимое в backup и удалять backup-1... Или что-то типа того.

Было бы здорово, если бы ccross умел простые операции upload/download файлов и папок из облака: как с ftp - без предварительного осмотра всего его содержимого.

from cloudcross.

В вашем случае надо авторизоваться в папке ~ или скопировать файл .ondr в ~.
Далее, там же создать файл .include с содержимым

/backup

и затем находясь в ~ выполнить

ccross --provider onedrive --use-include --force upload

при этом локальное содержимое backup будет совмещено с удаленным (удаленные файлы, при совпадении путей, будут заменены локальными). Но, как я понял, у вас

~/backup/Sub-M+1

поэтому локальные папки из backup будут просто выгружены в облако. Но, в любом случае, --dry-run в первый раз будет не лишним.

По поводу upload/download без предварительного получения информации об облаке - надо подумать. Возможно что то подобное добавлю в следующих версиях.

from cloudcross.

Пробую...
Кажется проверка формата Include List поломана у всех провайдеров. Например:
https://github.com/MasterSoft24/CloudCross/blob/master/src/Dropbox/msdropbox.cpp#L526
Должно вроде быть QRegExp regex2(this->includeList);

from cloudcross.

Да, похоже на то. Последние коммиты от @futuarmo я еще не тестировал - занят прикручиванием Fuse, так, что ошибка имеет место быть. Сейчас исправлю

from cloudcross.

Как насчет опции, чтобы в readLocal() запретить хождение по символьным ссылкам? Т.к. я запускаюсь в ~/ он быстро находит там /home/truf/.config/teamviewer10/dosdevices/c: прыгает на /home/truf/.config/teamviewer10/drive_c/доходит до /home/truf/.config/teamviewer10/drive_c/users/truf/My Documents/.config/teamviewer10/dosdevices/c:, переходит назад на /home/truf/.config/teamviewer10/drive_c/ и дальше летает кругами.

Я себе отключил.

from cloudcross.

Это обойти можно так. Создать папку ~/ccross-working
В ней сделать ссылку на ~/backup
И уже из ccross-working запускать синхронизацию.

А как бы вы предложили назвать эту опцию?

from cloudcross.

А как бы вы предложили назвать эту опцию?

У меня нет хороших идей

from cloudcross.

Есть еще проблема при создании папок. Получал ответ Bad request пока тут не заменил req->setRequestUrl("https://api.onedrive.com/v1.0/drive/root:/"+object->path+":/children"); на req->setRequestUrl("https://api.onedrive.com/v1.0/drive/root:"+object->path+":/children");
Я так понимаю, что object->path всегда начинается со слеша и они удваиваются.

from cloudcross.

Еще проблема - объем данных большой, пока серверные файлы прочитает, пока хеши из 50 гб локальных данных наделает, пока загружает на сервер... идет время. И в какой-то момент я оказываюсь тут с replyErrorText == "Host requires authentication", errorCode == 204 и следующей строкой в заголовке:
"WWW-Authenticate"
"Bearer realm="OneDriveAPI", error="expired_token", error_description="Auth token expired. Try refreshing."

После чего все последующие файлы в списке синхронизации завершаются тем же.

Полагаю, любой реквест к API может получить такой ответ и его нужно правильно перехватить и обработать.

from cloudcross.

Кроме того, до экспирации токена несколько файлов не были переданы с ошибкой а-ля:
Error transferring https://api.onedrive.com/up/eyJSZXNvdXJjZUlEIjoiODZBRTc2Qzc1MTdEMTMxMyExMjgyNjgiLCJSZWxhdGlvbnNoaXBOYW1lIjoiSW1hZ2UtMDQ3OC5wbmcifQ/4myHHT04zhj-2y7xLziHoxgS41MnXi4o9So5uFfr-7T_BJGS5hKN7w2n6dENOWrmjR3wiHmXG6ZwRkoPNcvZ3jxYKTEOjJJjFaPuQxYvgEv9U/eyJOYW1lIjoiSW1hZ2UtMDQ3OC5wbmcifQ/4wnaXsOF5JOrFOIwZEwU7z1ZtinJG9OMijkFaxhvAMDB8s0HYN75t2FzQmquZ6aBwNg6Z-pV2BCYP-pF7SEfqpd3ULFJ2q8FeUkxyisYiLj6V5Ic5gKodNT3aMm6QHkYvpDQVRiKbUg593pSUsSxXi-5jfx8ad1KI-xWjCXTZZKxsO3__SbNpGWkpS-1cPCyCuhMgxMk/7uyzcOzcOAUwISO34YrYa9vG4nqG66s0cQ0r_cqQCpOslIIXUD4xmwip-EjAd0cioby9ig0ge9PBQVHH6ue33ERFUZyMPD-_W6m47jEvVvY_vsDD2dSDNDlguEj-byFB02QBos7vnRJhPkSd71GpqfKIY7t_1ip0wyfVYNfLuSxe3QJ9v8okRvzi3eX-jzCDQWU1yRh5/N_3Lzd92B3twb6UXgKn8BxW65dNvduOdKEnOf53JVrVLwlZ5mLY7pAjB64OrXT8V8z2A8j3Tkeu9vnAtBLbPWlaY5Tr38 - server replied: Internal Server Error /backup/nic_modified/0157.png Forced uploading.

Нужен механизм, делающий N попыток выполнить неудавшийся запрос, прежде чем перейти к следующему.
Например как у bash-onedrive-upload для некритических ошибок
https://github.com/fkalis/bash-onedrive-upload/blob/master/onedrive.cfg#L24

from cloudcross.

И наконец - скорость передачи была ~0.5 Mb/s. Хотя OneDrive 3-мя потоками через web интерфейс качал на ~2.5 Мб/с. Во-первых, потому что тут стоит явно дебажное ограничение на размер передаваемого на сервер куска в <10Кб. Тогда как комментировано 59MB. Кстати, у bash-online-upload он больше 100Мб и настраиваемый
https://github.com/fkalis/bash-onedrive-upload/blob/master/onedrive.cfg#L20

Во-вторых - файлы отправляются последовательно, тогда как web интерфес заливает сразу 3, а bash-online-upload двумя потоками.
https://github.com/fkalis/bash-onedrive-upload/blob/master/onedrive.cfg#L14

Уверен, всем облакам это бы пригодилось.

Итого, нужно 3 вещи:

1. token refresh
2. retry in case of minor errors.
3. several requests in parallel.

from cloudcross.

API говорит

To upload the file, or a portion of the file, make a PUT request to the uploadUrl received when the session was created. You can either upload the entire file in one fragment up to 60 MiB (60 * 1024 * 1024 bytes), or you can break the file into multiple fragments and upload each one separately.

Ограничение <10Кб. , действительно, осталось дебажное - тут надо поправить.

Internal Server Error /backup/nic_modified/0157.png Forced uploading.

Это, как я понял, протух токен. Решить можно вкупе с реализацией нескольких попыток. Займусь.

А вот с многопоточностью сложнее. Тут уже, как мне кажется, архитектурное ограничение. Хотя, теоретически, и тут можно что то придумать. Типа, разбить syncFileList на несколько частей и запускать doSync в потоке.

from cloudcross.

Типа, разбить syncFileList на несколько частей и запускать doSync в потоке.

Да, мне кажется проще всего иметь общий пул объектов MSFSObject из которого потоки будут на перегонки брать по одному и обрабатывать пока пул не опустеет.
И создание папок нужно не забыть поправить.

from cloudcross.

С общим пулом могут race conditions получиться. Про папки не забуду, естественно

from cloudcross.

Released all requests except few retries after minor errors.
Today (Sep 9, 2017) all this features placed in dev branch.

from cloudcross.