Comments 75
Пишите еще!
«выбор пал бы на Cowboy, так как он предоставляет больше возможностей по определению проблем с соединением» — сколько боли и бессонных ночей я слышу за этой фразой! Интересно было бы почитать, какого рода проблемы возникали и как вы их решали.
Вопрос не в тему, но мне так и не удалось заставить работать WebDav под XP SP3. Патчи указанные у вас на сайте не помогли. Самое интересное, что после чистой установки обычно один раз подключится удается, а оптом пишет, «Неправильное имя папки. Задайте другое имя.»
Это будет как то исправляться или для XP уже ждать нечего.
Это будет как то исправляться или для XP уже ждать нечего.
UFO just landed and posted this here
Erlang был выбран тоже потому что команда была с ним хорошо знакома? (ejabberd)
Охтыжё… Мой диплом, только в промышленном масштабе :)
Ну как всегда… На самом интересном месте…
Ждем новых откровений!
А расскажите как вы определяете изменение файла? И как следствие необходимость обновления мета-информации о нём в базе и оповещения клиентов о синхронизации.
планируется увеличивать объемы хранилища (за плату разумеется)?
облако гугла совсем не устраивает, как только объем файлов превышает 100гб клиент начинает отваливаться (windows)
облако гугла совсем не устраивает, как только объем файлов превышает 100гб клиент начинает отваливаться (windows)
Вот эта расширяемость вебдава — и есть его беда. Его расширяют как-попало, как клиенты, так и серверы. Майкрософт вон себе кастомную авторизацию туда всобачила — хрен подключишся левым клиентом, информацию о занятом\свободном месте пятью разными способами разные сервера возвращают (а большинство — вообще не возвращает), кто-то аплоадид файлы через PUT, кто-то через POST (причём иногда и тем и тем, а иногда ТОЛЬКО чем-то одним), где-то есть докачка, а где-то нету, кто-то encode\decode именам файлов в полях делает, а кто-то — нет. Яндекс вот себе нотификации об изменениях придумал. Думаете их до этого не придумывали? 150 раз. Думаете, способ Яндекса станет стандартом, войдет во все клиенты? Хрен там.
Из-за всего этого бардака клиент ВебДава со временем либо превращается в монстра с кучей «если это сервер такой-то — то делаем вот-так», либо перестаёт быть совместимым с рядом серверов.
Грустно.
Из-за всего этого бардака клиент ВебДава со временем либо превращается в монстра с кучей «если это сервер такой-то — то делаем вот-так», либо перестаёт быть совместимым с рядом серверов.
Грустно.
До сих пор не удалось подключиться по WebDAV к ЯндексДиску из WinXp sp3. Поправите когда-нибудь или стоит распрощаться с надеждой?
Тут уже выше об этом спрашивали. Обычно эта ошибка возникает при проблемах с подключением к серверу, но бывают случаи, когда например браузером можно нормально подключиться к вебдав-серверу (можно попробовать скачать какой-нибудь файл), а Windows клиент всё-равно выдаёт «Неправильное имя папки». Точную причину этого выяснить не удалось, клиент при этом даже не подключается к серверу и с нашей стороны мы не можем избавить пользователей от этой проблемы.
Увидел пост выше, извините за повтор.
А свой собственный клиент создать, взамен стандартного, который позволял бы подключать ЯндексДиск как сетевой?
А свой собственный клиент создать, взамен стандартного, который позволял бы подключать ЯндексДиск как сетевой?
Мы делаем клиенты для синхронизации. Делать приложения для доступа по сети мы не планировали. Для этого есть стандартные клиенты.
Эти клиенты не позволяют подключать диск как сетевой, чтобы данные становились прозрачно доступными для всех.
Если хочется прозрачности для работы приложений, то лучше пользоваться синхронизацией. Обновления файлов по сети могут приводить к ошибкам. У нас были обращения в саппорт по поводу проблем с приложениями, работавшими с содержимым Яндекс.Диска, который был подключён встроенным в MacOSX расширением Finder-а.
Вот сегодня поставил чистую XP SP3 на виртуалку, никаких проблем с подключением. Перезагружался. Несколько подключений делал всё ок. Рядом стоит таже винда но слегка загаженая, там не работает. Видимо кто то из стандартного набора прог обновляет поддержку webdav и ломает её тем самым. Вычислить бы кто это и что меняет.
Попробуйте решение, описаное здесь: chapters.marssociety.org/webdav/
Также стоим перед выбором. WebDAV или GIT?
У нас одним из камней является важность версионирования.
Текущая система хранения документов позволяет создавать версии, но не позволяет править файлы прямо на сервере. Приходится скачивать, а потом закачивать обратно. Это проблема.
Наслышаны о WebDAV и его возможности работать с версиями, но в Яндекс.Диске эта возможность отсутствует. Было бы интересно раскрыть эту часть. Планировали? Решали? Разбирали?
У нас одним из камней является важность версионирования.
Текущая система хранения документов позволяет создавать версии, но не позволяет править файлы прямо на сервере. Приходится скачивать, а потом закачивать обратно. Это проблема.
Наслышаны о WebDAV и его возможности работать с версиями, но в Яндекс.Диске эта возможность отсутствует. Было бы интересно раскрыть эту часть. Планировали? Решали? Разбирали?
Версионирование — это полезное дополнение к обычному файловому хранилищу. Наличие этой фичи в протоколе — дополнительный плюс. Однако, на текущем этапе мы не считаем её критичной, так как есть более востребованые функции.
Сразу вылезает проблема как хранить версии и быстро получать конкретную версию файла. Я хранил просто копии, но это было ни разу не подходящим решением, а сделать бинарные diff'ы не позволили сроки.
Хранение диффов сильно усложняет работу с файлами. Конечно, всё решается, но чем проще система, тем легче её поддерживать. Поэтому лично я бы воспользовался хранением диффов только в случае жёстких требований по минимизации хранилища.
Насколько я понимаю, у вас будет как раз подобный случай, если надумаете делать версионирование. Я конечно не знаю насколько много файлов хранится на яндекс.диске, но если хотя бы 10% будут иметь больше десятка версий, то их хранение будет накладно.
Я когда над этим вопросом думал, у меня вырисовывалась гибридная схема, что часть файлов не версионируется вообще, часть файлов версионируется до определённой глубины, оставшаяся часть версионируется от и до.
При версионировании используются бинарные/текстовые диффы(mimetype, да) и возможно хранятся полные копии, некоторых версий, если к ним надо иметь быстрый доступ — суть кэш.
Ну и соответственно никаких веток и мержей.
Но диплом закончился, а внедрение в «боевые условия» не пошло. И к лучшему наверное :)
Я когда над этим вопросом думал, у меня вырисовывалась гибридная схема, что часть файлов не версионируется вообще, часть файлов версионируется до определённой глубины, оставшаяся часть версионируется от и до.
При версионировании используются бинарные/текстовые диффы(mimetype, да) и возможно хранятся полные копии, некоторых версий, если к ним надо иметь быстрый доступ — суть кэш.
Ну и соответственно никаких веток и мержей.
Но диплом закончился, а внедрение в «боевые условия» не пошло. И к лучшему наверное :)
Для исключения порчи данных была бы полезна хотя бы возможность заливать файл, если текущая версия равна указанной клиентом (последней, про которую знает клиент).
Вопрос не в тему, а почему у подключенного пустого Яндекс.Диска (10 Гб, Win8) в проводнике показывает 55 гб (из которых свободно 7 Гб). Что за баг?
Скажите, ждать ли самостоятельный клиент для Убунту, или навечно останется Наутилус?
Скажите, а файлы одного клиента, я так понимаю, могут лежать на разных стореджах? Как вы решаете эту проблему? Сервер на erlang проксирует отдачу файлов клиенту с разных машин? или используйте 301 редирект в таком случае? вроде как часть клиентов его использует, но к сожалению далеко не все.
…
Когда будет возможно расшаривать папки или по крайней мере файлы мультиселектом?
Странно, что про FTP вы пишете «требует для подключения специальные приложения». В большинстве современных ОС есть встроенная поддержка FTP.
А rsync вообще не рассматривали, получается? Он ведь, вроде как, именно для ваших целей и разработан — для синхронизации файлов.
davfs под Линуксом — это настоящая боль.
0. Вообще нет локальной копии данных.
1. Через GUI-клиент нельзя работать с данными напрямую и вообще все GUI-клиенты — это кошмарное вышивание бисером. Только консоль и Миднайт, только хардкор!
2. davfs однопоточен, поэтому пока сбрасываются буфера любая прога, сунувшаяся в каталог на davfs, тупо зависает. Если идёт запись больших файлов то это капут.
3. Монтирование davfs — не самая удобная операция. Кстати, в вашем мануале не написано, что надо делать /etc/davfs2/davfs2.conf => delay_upload 0, иначе пункт 2 становится фатальным (монтировать просто не следует — при попытке залить в мегабайты данных всё заклинивает без какого-либо фидбэка). Кстати, это всё требует рута на компе, чего в продвинутой организации может быть и не у всех.
А теперь сравните это с Дропбоксом — я вообще ничего не делаю, кроме разовой установки клиента за пару минут, и дальше всё работает годами без малейшего внимания с моей стороны, не тормозит ни на йоту, прерывается моментально (например, при перезагрузке компа) и копия всего лежит локально — с-но локальная скорость работы с данными, а в случае сбоя сети, например, вообще никаких проблем не возникает. Как поймает сетку, так сам и синхронизирует.
Моё убеждение: для облачного хранилища рулит только подход Дропбокса, а всё остальное это просто баловство.
0. Вообще нет локальной копии данных.
1. Через GUI-клиент нельзя работать с данными напрямую и вообще все GUI-клиенты — это кошмарное вышивание бисером. Только консоль и Миднайт, только хардкор!
2. davfs однопоточен, поэтому пока сбрасываются буфера любая прога, сунувшаяся в каталог на davfs, тупо зависает. Если идёт запись больших файлов то это капут.
3. Монтирование davfs — не самая удобная операция. Кстати, в вашем мануале не написано, что надо делать /etc/davfs2/davfs2.conf => delay_upload 0, иначе пункт 2 становится фатальным (монтировать просто не следует — при попытке залить в мегабайты данных всё заклинивает без какого-либо фидбэка). Кстати, это всё требует рута на компе, чего в продвинутой организации может быть и не у всех.
А теперь сравните это с Дропбоксом — я вообще ничего не делаю, кроме разовой установки клиента за пару минут, и дальше всё работает годами без малейшего внимания с моей стороны, не тормозит ни на йоту, прерывается моментально (например, при перезагрузке компа) и копия всего лежит локально — с-но локальная скорость работы с данными, а в случае сбоя сети, например, вообще никаких проблем не возникает. Как поймает сетку, так сам и синхронизирует.
Моё убеждение: для облачного хранилища рулит только подход Дропбокса, а всё остальное это просто баловство.
Вот бы фотку, где все это храниться…
Хорошо сделано. В OS/2 при помощи NetDrive с NDPDAV плагином работает без проблем(я думаю что и cadaver тоже заработает). Понятное дело что на сервер уходят только файлы, без расширенных атрибутов, но для этого наверное нужно использовать ваше расширение протокола. Как я понимаю можно хранить любую метаинформацию?
При закачке большого файла (2 гига) курлом из под freebsd, под конец закачки (примерно час)
выдает сообщение:
SSL read: error:00000000:lib(0):func(0):reason(0), errno 54
Маленький файл заливается без проблем.
выдает сообщение:
SSL read: error:00000000:lib(0):func(0):reason(0), errno 54
Маленький файл заливается без проблем.
Кажется, webdav в яндексе сломался :'-(
github.com/elfmz/far2l/issues/606
github.com/elfmz/far2l/issues/606
Уже недели две пытаюсь понять в чем дело. Пробовал с разных мест (Москва, Самара, DO), под разными учетками (с плюсом и без).
Мелкие файлы залетают, большие грузит процентов 5 и скорость встает.
Поддержка Я сказали — мы тут не при чем, пользуйтесь нашим клиентом и все.
Все ссылки из хелпа на вебдав они выпилили.
Если найдете решение — дайте знать!
Поломали WebDAV м всех загоняют на closed-source клиент. Его же писали совместно с Касперским, да? Ну OK. Можно поставить этот странный яндекс-диск клиент в докер и дать ему права на ОДНУ папку хоста для синхронизации и подрезать хосты на сети. Пусть болтается контейнер.
Далее эту же папку можно расшарить из хоста по SMB или даже сделать _частный_ WebDAV. Тогда у существующих клиентов придется просто поменять URL на этот собственный WebDAV. Минус — теперь нельзя будет просто «подключить» яндекс-диск, а надо иметь локально такой же объем, как на я-диске для синхронизации.
Далее эту же папку можно расшарить из хоста по SMB или даже сделать _частный_ WebDAV. Тогда у существующих клиентов придется просто поменять URL на этот собственный WebDAV. Минус — теперь нельзя будет просто «подключить» яндекс-диск, а надо иметь локально такой же объем, как на я-диске для синхронизации.
bobuk, bedmitry, сообщество ждёт ответа! А как же "OpenSource — наше всё"?
См. также https://yandex.ru/blog/apidisk/problemy-pri-otpravke-faylov-po-webdav
Яндекс не планирует выпустить официальный пресс релиз о работе WebDAV?
Все это выглядит как саботаж открытого протокола, скорость передачи данных моментально падает в 0.
В тех поддержке сотрудник проговаривает одну и ту же причину, я пишу про работу протокола WebDAV, он мне отвечает про сторонние приложения.
Приобрел у вас 25 ТБ диска, а не могу туда семейный архив фото и видео за 15 лет загрузить, 14 ТБ данных, все встало колом после 85 тыс снимков отправленных через ваш клиент (замечу успешно, но нужен ПК), держать включенным ПК просто неудобно.
Решил отправить вам эти данные по WebDAV с NAS, на котором эти данные и хранятся, заодно настроить двустороннюю синхронизацию, чтобы не грузить все это руками каждый раз.
Выяснилось что Яндекс режет WebDAV, почти сразу как начинается загрузка, до такой скорости что 14 ТБ я буду передавать к вам лет 250.
Вот вы мне объясните как клиенту, у меня 1Гбит канал, я приобрел 25 ТБ хранилища, для чего вы мне режете скорость по WebDAV, я же приобрел 25 ТБ не для того чтобы там 1 фото держать?
Причем заплатил авансом за год :(
Sign up to leave a comment.
Как мы выбрали и реализовали WebDAV в Яндекс.Диске