Uploads currently not working: YaDisk or ydcmd problem?
Closed this issue · 17 comments
I'm currently experiencing problems uploading to Yandex Disk with ydcmd on macOS 10.14.6.
When I run it in verbose & debug mode, I'm getting this, but no upload:
ydcmd.py --token=<token> --verbose --debug put /path/to/<filename> /YandexDiskSubfolder/<filename>
--> GET https://cloud-api.yandex.net/v1/disk/resources?path=disk%3A%2FYandexDiskSubfolder%2F<filename>&limit=0&offset=0
--> Connected to cloud-api.yandex.net:443 (TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256)
--> md5/sha256: /path/to/<filename>
After that ydcmd immediately exits.
Is this a Yandex Disk problem or a ydcmd bug?
Seems to be working again, so apparently it was a Yadisk server problem.
Problems started again, this time verified in verbose/debug mode. Getting errors, namely Retry 1/3: ('The read operation timed out',) from 1/3 to 3/3, with the final error ('The read operation timed out',). Upload speed is a rollercoaster, going up, going down etc. However, despite the error messages the files are actually uploaded to YandexDisk, but ydcmd.py doesn't register it as such, acts as if there was an error. This seems to be primarily a server issue, but maybe ydcmd can be tweaked to ignore these "read operation" errors. (?)
Try to increase --timeout or split files to smaller size.
I have the same problem started about the same time:
ydcmd put filename.zip
takes a lot of time and gives the 'The read operation timed out' error message.
The file, however, is copied to yandex disk OK. There was no such issue a few months before.
It is also happening for me past few weeks for one particular VPS. I copy my website backup to YDisk every day, the dump is 9.5GB in size. It had been working fine for months but now it sits there syncing forever... and sync never completes.
I'm also getting on another sever when syncing
Unsupported filesystem object: /backup/ia2.2019-10-16_01-09-09.tar after the first file is uploaded and the older one is to be deleted.
Can you have a look and see if there is a change in API or something that needs to be updated in YDCMD ?
there is simple solve for this issue.
try to rename your files to something that don't have archive extension.
Something like this: myfile.part1
It works.
yandex don't want to keep our backups on it's servers.
please don't tell about this in others places cause they can block not by extension but by mime types.
progreccor, your are correct:
# 8Mb file orig.zip
cp orig.zip f.zip
cp orig.zip f.zip.gz
cp orig.zip f.zip.qqq
# .qqq finishes almost immediately
$ ydcmd put f.zip.qqq
Transfer: f.zip.qqq (7M) -> disk:/f.zip.qqq
# .zip takes a while, but the file is eventually copied
$ ydcmd put f.zip
Transfer: f.zip (7M) -> disk:/f.zip
('The read operation timed out',)
# .gz same thing as with .zip
Transfer: f.zip.gz (7M) -> disk:/f.zip.gz
('The read operation timed out',)
I just tested .zip and .zip.upload in debug mode, and both finished fine, no timeout. So this behavior seems to be intermittent.
it's 100% YaDisk problem. "official" php sdk from their rest api documentation have same bug with upload (only archive extensions (tar/zip/gz etc))
В данный момент общаюсь с саппортом яндекса по поводу этого бага. Первый ответ прилетел почти сразу, но единственное, что там было - "пользуйтесь официальными клиентами". Баг явно есть (или так задумано ими, но они никогда в этом не признаются) и он повторяется в php версии SDK, при загрузке файла с расширением архива скрипт уходит в бесконечную загрузку. Так как плачу за диск, буду требовать починить мне загрузку как было :) (тоже около месяца назад этот баг всплыл)
I have had occasional positive results with the .dmg extension on macOS, i.e. not zip/rar/7z, but I'm now adding a nonsense extension to every file meant for upload, and it's been working OK for a couple of weeks now. But yeah, most probably YaDisk, not ydcmd.
PS: I also tried keeping the local file as-is and only changing the remote file name (put filename), but that didn't work… it seems you have to actually mv your local file first, from e.g. .zip to .zip.upload, and then upload. I even insert a touch for good measure before upload.
В данный момент общаюсь с саппортом яндекса по поводу этого бага. Первый ответ прилетел почти сразу, но единственное, что там было - "пользуйтесь официальными клиентами". Баг явно есть (или так задумано ими, но они никогда в этом не признаются) и он повторяется в php версии SDK, при загрузке файла с расширением архива скрипт уходит в бесконечную загрузку. Так как плачу за диск, буду требовать починить мне загрузку как было :) (тоже около месяца назад этот баг всплыл)
Их мало волнуют твои деньги. Саппорт у яндекса всегда был охамевшим. Поэтому от них будет ответ - используйте официальные клиенты, иначе вы нарушаете "гарантию". :)
Поэтому лично я сомневаюсь что удастся чего либо добиться. Но все равно пожелаю удачи. Отпиши потом чем кончится.
Их мало волнуют твои деньги. Саппорт у яндекса всегда был охамевшим. Поэтому от них будет ответ - используйте официальные клиенты, иначе вы нарушаете "гарантию". :)
Поэтому лично я сомневаюсь что удастся чего либо добиться. Но все равно пожелаю удачи. Отпиши потом чем кончится.
Да я так и думаю в принципе. но вроде бы заинтересовались, так как я им прислал видео работы как бы "официального" php sdk (есть тут https://yandex.ru/dev/disk/rest/), который также имеет этот баг. Пока пытаюсь пробиться хотя бы на 2 уровень тех. поддержки, так как 1 уровень просит меня отправить им папку .sync, которой у меня быть не может при использовании ydcmd или php sdk :)
Да я так и думаю в принципе. но вроде бы заинтересовались, так как я им прислал видео работы как бы "официального" php sdk (есть тут https://yandex.ru/dev/disk/rest/), который также имеет этот баг. Пока пытаюсь пробиться хотя бы на 2 уровень тех. поддержки, так как 1 уровень просит меня отправить им папку .sync, которой у меня быть не может при использовании ydcmd или php sdk :)
Да, логичный ход. Посмотрим чем кончится. В принципе им возразить наверное будет нечего.
Либо деньги вернут :)
Видимо Яндекс.Диск всё... залез в их блог, а там...
https://yandex.ru/blog/apidisk/ne-zagruzhayutsya-fayly-s-rasshireniem-zip-rar-bolshikh-razmerov
https://yandex.ru/blog/apidisk/problemy-pri-otpravke-faylov-po-webdav
https://yandex.ru/blog/apidisk/ochen-silnoe-padenie-skorosti-zagruzki-faylov-cherez-rest-api
https://yandex.ru/blog/apidisk/oshibki-pri-zagruzke-faylov-cherez-klienty-webdav
и API и WebDAV судя по всему убили...
ТП отмазывается "У REST API нет собственной выделенной поддержки. Существует поддержка Диска, но мы не можем гарантировать работу сторонних инструментов..."
апи есть, документация есть, поддержки нет, гарантии работоспособности тоже нет...
API у диска странный предмет, вроде бы есть, а вроде бы нет.
@deadsandro ну по сути так то все работает, просто не надо заливать файлы с расширением .zip и так далее.
в-общем так и не ответили ничего из поддержки диска и тикет в поддержку API (позже нашел контакты) тоже проигнорировали. А написать решил дополнительно еще по другой причине. Возможно мне показалось, но вроде бы они включили проверку по mime и отключили загрузку файла, теперь на части серверов утилита перестала в принципе догружать файл до конца даже переименованный. в зависимости от размера часть загрузилась успешно (совсем маленькие архивы), часть грузилась медленно и выпадала с ошибкой, но попадала в диск (30-50 мб), а больше 100 уже переставали грузиться совсем, грузились медленно и выпадали с ошибкой без появления в диске.
в-общем так и не ответили ничего из поддержки диска и тикет в поддержку API (позже нашел контакты) тоже проигнорировали. А написать решил дополнительно еще по другой причине. Возможно мне показалось, но вроде бы они включили проверку по mime и отключили загрузку файла, теперь на части серверов утилита перестала в принципе догружать файл до конца даже переименованный. в зависимости от размера часть загрузилась успешно (совсем маленькие архивы), часть грузилась медленно и выпадала с ошибкой, но попадала в диск (30-50 мб), а больше 100 уже переставали грузиться совсем, грузились медленно и выпадали с ошибкой без появления в диске.
сейчас проверил у себя на сервере - у меня архивируется tar.gz
затем файл бьется на части и выгружается на яндекс диск. Размер частей - по 500мб.
Размер сайта - 8гигов.
Все выгружается корректно и без проблем.