Same problem as https://github.com/vitalif/grive2/issues/5

[xpro2004]

sync "./i/52.b" changed in local. uploading
request failed with 412, retrying whole upload in 5s
request failed with 412, retrying whole upload in 5s
request failed with 412, retrying whole upload in 5s
request failed with 412, retrying whole upload in 5s
request failed with 412, retrying whole upload in 5s

Latest release installed.

[vitalif]

Please retry with the latest master, it should print response body of these 412's - maybe we'll learn something about them at last...

[mafe]

I have the same problem here with following output:

. retrying whole upload in 5s
request failed with 412, body: {
 "error": {
  "errors": [
   {
    "domain": "global",
    "reason": "conditionNotMet",
    "message": "Precondition Failed",
    "locationType": "header",
    "location": "If-Match"
   }
  ],
  "code": 412,
  "message": "Precondition Failed"
 }
}
. retrying whole upload in 5s

[vitriolix]

I get this too, accidentally duped it here:

#21

[vitalif]

This should mean google drive thinks the file is changed during sync... But as I understand the offending files couldn't be changed during sync at google side?

[vitriolix]

I definitely am not changing any files during sync

[vitriolix]

I did change file in between syncs (rearranged some directory locations) though

[vitalif]

I'm now sometimes getting 412's myself... but I don't yet understand what triggers them O_o they usually go away after restarting grive, but this ends up with duplicate files...

[vitalif]

I believe 412 is fixed in master by using multipart uploads - now file metadata and contents are uploaded in a single request so the situation where the second request "does not see" the result of the first one due to the async nature of google drive service is impossible.
Please test and reopen the issue if you still experience it.

[xpro2004]

After installing new version:

./grive
Reading local directories
Synchronizing folders
Reading remote server file list
Неверная инструкция(core dumped)

[xpro2004]

Don't know how to repeopen the ticket..

[vitalif]

O_o. Это какая-то другая ошибка. Попробуй под gdb запустить (gdb --args grive и потом в консоли gdb уже run). Когда сдохнет - скажи в консоли gdb "bt" и он напечатает стек. И напиши что там будет сюда...

[xpro2004]

Synchronizing folders
Reading remote server file list
[New Thread 807c06400 (LWP 101258/grive)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 807c06400 (LWP 101258/grive)]
0x0000000000461e18 in gr::State::Update ()
(gdb) bt
#0 0x0000000000461e18 in gr::State::Update ()
#1 0x0000000000460d96 in gr::State::FromRemote ()
#2 0x0000000000444e54 in gr::Drive::FromRemote ()
#3 0x0000000000447a6a in boost::_mfi::mf1<void, gr::Drive, gr::Entry const&>::operator() ()
#4 0x00000000004479c1 in boost::_bi::list2boost::_bi::value<gr::Drive*, boost::arg<1> >::operator()<boost::_mfi::mf1<void, gr::Drive, gr::Entry const&>, boost::_bi::list1<gr::Entry const&> > ()
#5 0x0000000000447912 in boost::_bi::bind_t<void, boost::_mfi::mf1<void, gr::Drive, gr::Entry const&>, boost::_bi::list2boost::_bi::value<gr::Drive*, boost::arg<1> > >::operator()gr::Entry ()
#6 0x0000000000445fb0 in gr::Drive::DetectChanges ()
#7 0x000000000040e049 in Main ()
#8 0x000000000040e54d in main ()
(gdb)

[vitalif]

O_o тогда попробуй ещё в CMakeCache.txt поменять CMAKE_BUILD_TYPE на Debug и ещё раз пересобрать и запустить пересобранную версию опять через gdb. Чтобы номера строк были.
Но это что-то очень странное - видимо где-то память портится, что ли...

[vitalif]

А, подозреваю что знаю кто виноват. Наверное std::string::replace так юзать как я хотел нельзя. Попробуй вот щас версию из мастера.

[xpro2004]

Не помогло.

This GDB was configured as "amd64-marcel-freebsd"...
(gdb) run
Starting program: /backup/gd/grive
[New LWP 101506]
[New Thread 807c06c00 (LWP 100802/grive)]
Reading local directories
Synchronizing folders
Reading remote server file list
[New Thread 807c06400 (LWP 101506/grive)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 807c06400 (LWP 101506/grive)]
0x0000000000461d58 in gr::State::Update (this=0x7fffffffcde0, e=@0x8085fd1a0) at /backup/grive2-master/libgrive/src/base/State.cc:232
232 return false ;
(gdb) bt
#0 0x0000000000461d58 in gr::State::Update (this=0x7fffffffcde0, e=@0x8085fd1a0) at /backup/grive2-master/libgrive/src/base/State.cc:232
#1 0x0000000000460cd6 in gr::State::FromRemote (this=0x7fffffffcde0, e=@0x8085fd1a0) at /backup/grive2-master/libgrive/src/base/State.cc:138
#2 0x0000000000444d94 in gr::Drive::FromRemote (this=0x7fffffffcdc0, entry=@0x8085fd1a0) at /backup/grive2-master/libgrive/src/base/Drive.cc:73
#3 0x00000000004479aa in boost::_mfi::mf1<void, gr::Drive, gr::Entry const&>::operator() (this=0x7fffffffc8a0, p=0x7fffffffcdc0, a1=@0x8085fd1a0) at mem_fn_template.hpp:165
#4 0x0000000000447901 in boost::_bi::list2boost::_bi::value<gr::Drive*, boost::arg<1> >::operator()<boost::_mfi::mf1<void, gr::Drive, gr::Entry const&>, boost::_bi::list1<gr::Entry const&> > (this=0x7fffffffc8b0, f=@0x7fffffffc8a0, a=@0x7fffffffc498) at bind.hpp:313
#5 0x0000000000447852 in boost::_bi::bind_t<void, boost::_mfi::mf1<void, gr::Drive, gr::Entry const&>, boost::_bi::list2boost::_bi::value<gr::Drive*, boost::arg<1> > >::operator()gr::Entry (this=0x7fffffffc8a0, a1=@0x8085fd1a0) at bind_template.hpp:47
#6 0x0000000000445ef0 in gr::Drive::DetectChanges (this=0x7fffffffcdc0) at iterator:1136
#7 0x000000000040df89 in Main (argc=1, argv=0x7fffffffdae0) at /backup/grive2-master/grive/src/main.cc:197
#8 0x000000000040e48d in main (argc=1, argv=0x7fffffffdae0) at /backup/grive2-master/grive/src/main.cc:216
(gdb)

[vitalif]

Очень оригинально... что бы это вообще значило... ок, проверю под freebsd.

С забитым диском кстати не пробовал, не видел текст ошибки?

[xpro2004]

Не смог проверить, купил 100Гб

[vitalif]

Хех, круто, проверил под FreeBSD - действительно был SIGILL. НО зато шланг (clang) сразу выдал пару варнингов, после исправления которых всё стало ок. Причём одним из варнингов был невиртуальный деструктор у класса LogBase, и из-за этого сразу пофиксилась утечка памяти, которую видел valgrind, но я никак не мог догнать, где же она есть-то))

[vitalif]

я тебе кстати номер карточки сбера так и не сказал)) куда тебе его скинуть?

[xpro2004]

Напиши вконтакте.

[vitalif]

У тебя там "пользователь ограничил круг лиц которые могут посылать ему сообщения"

[xpro2004]

Какой-то баг стал появляться после этого фикса. Может совпадение и что-то поменяли в гугле в это время - не знаю.
Все файлы занимают на диске в 2 раза больше места чем размер файла. Смотрю по свойствам файлов в гугле.
Думал пройдёт со временем - но не проходит, файлы регулярно обновляются через grive.

Жесть. Может там по два раза что-то пишется в какие-то дисковые буфера?

[vitalif]

Э... в смысле размер файлов правильный, но занимают больше места в фс?

[xpro2004]

Да.
В свойствах файла в веб интерфейсе гугл-диска так и говорит. Размер файла:
X, Размер на диске: 2*X

7 ноября 2015 г., 19:00 пользователь Vitaliy Filippov <
[email protected]> написал:

Э... в смысле размер файлов правильный, но занимают больше места в фс?

—
Reply to this email directly or view it on GitHub
#12 (comment).

С уважением,
Alexander Evdokimov

[vitalif]

А... в гугл диске? O_o очень оригинально

[vitalif]

Может там версий несколько создается? Там их нельзя глянуть?

[xpro2004]

Если про приложение - то под андроидом, то же самое.
Версий нигде не вижу. Везде один файл.

[vitalif]

Я имею ввиду, файл занимает больше места на локальном диске или на сервере (на стороне гугла)?

[vitalif]

Короче что-то я не очень понимаю как это вообще возможно)
У меня свойства в веб-интерфейса гугл диска выглядит так:
Тип: Изображение
Размер: 35 КБ (35 367 байт)
Использовано: 35 КБ (35 367 байт)
Расположение: Мой диск
...

[xpro2004]

Удалил файлы на гугл-диске, запустил grive по новой, вроде прошло.
Очень странно.

[xpro2004]

Кажется снова та же проблема. Ни с того, ни с сего, второй день подрят:

exception: /backup/grive2-master/libgrive/src/protocol/AuthAgent.cc(142): Throw in function long gr::AuthAgent::CheckHttpResponse(long, const std::string &, const http::Header &)
Dynamic exception type: N5boost16exception_detail10clone_implIN2gr4http5ErrorEEE
[PN2gr4http17RequestHeadersTagE] = If-Match: "fbeGFVkCD3tGFpdjp1CYyuwDABw/MTQ0OTAxNTgwNzcwNA"
Content-Type: multipart/related; boundary="file_contents"
Content-Length: 1269906589
Authorization: Bearer ya29.QAIIyU7RL5R-ARP_Y5PslhC9V00Wa9a-wh9Vb8bjIMt21WiTEvj6FdSbAI8G5lj0OvBp
GData-Version: 3.0

[PN2gr4http6UrlTagE] = https://www.googleapis.com/upload/drive/v2/files/0B4F71yDn-KQ9elJxcTBPaHc0Vms?uploadType=multipart
[PN2gr4http15ResponseBodyTagE] = {
"error": {
"errors": [
{
"domain": "global",
"reason": "conditionNotMet",
"message": "Precondition Failed",
"locationType": "header",
"location": "If-Match"
}
],
"code": 412,
"message": "Precondition Failed"
}
}

[PN2gr4http18ResponseHeadersTagE] = HTTP/1.1 412 Precondition Failed
X-GUploader-UploadID: AEnB2UqcysYeZUKfdY6o1qKEbTzzwZmoCOgwRaX-JEWEOAHOZ-Tdym0virOAS9zly297P8LersivFFeJs8JaRv8bd8ALH0BPkg
Vary: Origin
Vary: X-Origin
Content-Type: application/json; charset=UTF-8
Content-Length: 250
Date: Fri, 04 Dec 2015 06:35:24 GMT
Server: UploadServer
Alternate-Protocol: 443:quic,p=1
Alt-Svc: quic=":443"; ma=604800; v="30,29,28,27,26,25"

[PN2gr4http15ResponseCodeTagE] = 412