Вы просматриваете: Главная > Без рубрики > Яндекс.Диск vs Dropbox

Яндекс.Диск vs Dropbox

Лирическое отступление. Недавние события (назначение Кондолизы Райс в совет директоров облачного сервиса Dropbox) сподвигли к давно намечавшемуся: попробовать отечественного конкурента Яндекс.Диск. Я два года являюсь Pro-пользователем Dropbox — т.е., плачу деньги за дополнительное пространство, т.к. этот сервис очень мне пригодился и с ним я чувствую себя «сухо и тепло». И как активный пользователь, я не понимаю, на кой ляд назначать людей, бесконечно далёких от ИТ, в такую компанию (особенно если вспомнить былые «трудовые подвиги» Райс и её отношение к приватности). Поэтому, в тот же день, что я услышал эту новость, я решился установить себе Яндекс.Диск. Если хотите бесплатные 11Гб (по моему приглашению) — регистрируйтесь.

Зарегистрировать Яндекс.Диск (11Гб бесплатно)

По поводу приватности — всем понятно, что в случае надобности ваше электронное содержимое может оказаться под пристальным вниманием спецслужб. Но в мире нет ни единого сервиса с тотальной защитой. Dropbox за все годы моего с ним общения не хочет меняться ни в какую сторону, не слушает своих пользователей (в т.ч. тех, которые платят ему) — словом, ведёт себя, как зажравшийся в отсутствие конкуренции. Для меня одного этого достаточно для перехода. А уж учитывая моё патриотическое отношение к Яндексу… 🙂

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

Установка и настройка

При установке на разных системах иногда имеются проблемы (об этом ниже). Установщик спросил, какую папку определить под «диск», привычно попытался навязать сервисы Яндекса (прописывание поисковика в браузер, ещё какая-то ботва) — всё было, конечно, отключено. При вводе своего логина на сервисах Яндекса попадаешь в свой «диск». Настройки клиента и его взаимодействие с операционной системой на 90% схожи с тем же Dropbox, так что привыкать особенно ни к чему не пришлось.

Синхронизация в Windows-клиенте обычно идёт довольно быстро — сравнимо с Dropbox; всё зависит только от вашего интернет-подключения. А вот Android-клиент особой быстротой не порадовал, причём тест производился через то же самое подключение. Также не порадовало отсутствие хотя бы примерного прогноза времени окончания синхронизации. С момента старта клиента при входе в систему до окончания проверки базы проходит около пяти минут (проверено на объёме данных ~110Гб) — примерно столько же, сколько и у Dropbox на аналогичном объёме.

Больше бесплатного места

Яндекс.Диск даёт сразу 10Гб бесплатно (11Гб по моей ссылке). Тем, кому не хочется платить за сервис — самое оно, ведь Dropbox даёт только 2Гб и, похоже, пересматривать политику не собирается. Периодически у Яндекса случаются «раздачи» по каким-нибудь поводам.

Дополнительное место дешевле

100Гб у Яндекс.Диска стоят 1500 рублей в год — против 99$ у Dropbox. Двойная экономия налицо. Dropbox тарифы пару лет не пересматривал; впечатление, что им и так уже «совсем хорошо» и конкурентов нет.

Непонятная сходу тарифная политика

На данный момент у Яндекс.Диска три тарифа: 10Гб, 100Гб и 1Тб. Никаких промежуточных вариантов — что более, чем странно. Можно докупить место несколькими тарифами по 10Гб (или по 100), но это явно не особо удобно, хотя мне на первых порах так и придётся. И «доходишь» до этого не сразу. Плюс в том, что предлагаемая схема гибче, чем у Dropbox (там предлагаются неудобные фиксированные тарифы без возможности «докупить»).

Легковесные клиенты

Клиент Яндекс.Диска более легковесный — 39Мб против 67Мб у Dropbox (на текущий момент). То же касается и клиента под Android — 6Мб у Яндекс.Диска и 40Мб (!!!) у Dropbox. Под Android клиент действительно резв «невооружённым глазом», под Windows особой резвости не замечено, причём клиент Яндекс.Диска потребляет больше оперативной памяти (естественно, замерено на одинаковых объёмах информации).

Ошибки установщика

На одной из машин возникла ошибка «Не удалось скачать Яндекс.Диск». Судя по поиску, людей с этим делом обламывается немало. Как так можно было напортачить — неясно. У меня возникли и дальнейшие сложности — уже после скачивания полного дистрибутива: «Не удалось распаковать Яндекс.Диск». С этим оказалось сложнее — поиск ничего не давал. Поскольку я знаю свою систему вдоль и поперёк, я нашёл решение, заглянув в лог установки. В WinXP он находится здесь:

C:\Documents and Settings\[ваш_юзер]\Local Settings\Application Data\Yandex\Yandex.Disk\YandexDiskSetup.log

Там я узрел такую строку:

VerifyEmbeddedSignature for file ‘C:\Documents and Settings\All Users\Application Data\Yandex\Yandex.Disk\{3FE0EF39-1462-4094-9A42-43B4EE3C383B}\YandexDisk32SetupRu.exe’: Error is: 0x800b010a

Ошибка 0x800b010a возникает при каких-то там необновлённых сертификатах. Наконец-то я столкнулся с этим: сервис обновления сертификатов (update root sertificates) у меня был убран вручную в установке системы. 🙂 Я работал на этой самой системе десять лет и все десять лет все программы ставились исправно. А вот Яндекс.Диск показал мне, что отключать этот супер-полезный сервис, который пригождается раз в десять лет, не стоит.

Всё вышеописанное смотрится очень печально на фоне Dropbox. Зачем вставлять в программу такие невиданные грабли — неясно.

Непродуманная синхронизация

Клиент под Windows ведёт себя странно. Стоит сделать пустую папку или обновить маленький файлик — клиент начинает ворочаться пару минут и грузить процессор. Под Windows7 столкнулся с непонятными ошибками «Невозможно открыть файл», когда клиент не мог его синхронизировать и показывал на иконке файла «крестик». Так и не понял, с чем это связано — помогало простое пересохранение файла; возможно, это были разрешения на конкретной машине, хотя клиент работает из-под того же пользователя. Стало быть, если уж пользователь может открыть файл (а в той ситуации точно мог) — то и клиенту он должен быть доступен.

Ко всему прочему, клиент не сохраняет оригинальную дату файла при выгрузке. Из-за этого, на всех подключаемых после первой синхронизации машинах, даты файлов устанавливаются в дату загрузки на сервис. Это довольно-таки удивляет, хотя я сходу не назову причину для беспокойства, поскольку редко вообще когда этими датами интересуюсь. Но, как видите, всё-таки интересуюсь. Полагаю, сервис реализован на *nix-системах; там дата создания отсутствует, есть только дата модификации. Отсюда и растущие ноги, но ведь можно было устанавливать при выгрузке и загрузке правильную дату. Видимо, с этим делом в Яндекс.Диске вообще решили не заморачиваться.

Подытоживая данную тему: после Dropbox — опять печально.

Ошибки и непонятности клиента Яндекс.Диск

На одной из машин клиент, синхронизирующий примерно 110Гб информации, постоянно останавливал синхронизацию с непонятными ошибками в логах и мог висеть в таком состоянии по 2-3 часа, ничего не делая. Помогало только выключение-включение синхронизации вручную. Похоже, ситуацию спасла перезагрузка; больше с таким не сталкивался.

Иногда происходят какие-то «отказы чтения сервера» и клиент весело сверкает в трее восклицательными знаками. Через какое-то время всё образуется (и файлы нормально синхронизируются) — но, сдаётся, можно было как-то замаскировать весь этот цирк, раз уж серверы нестабильно работают.

Для работы клиента Яндекс.Диск зачем-то нужна служба BITS («background intelligent transfer service», или «фоновая интеллектуальная служба передачи»). У меня она, как уже догадывается читатель, была отключена десять лет и никому не требовалась, но после установки Яндекс.Диска в системный лог стали сыпаться ошибки о невозможности включения этой службы. После снятия блокировки система успокоилась и ошибками сыпать перестала; что это было — так и не понял. Клиент работал и с запрещённой службой.

WebDAV

Яндекс.Диск позволяет подключиться к сервису через протокол WebDAV. Это открывает грандиозную нишу для совместимости и разработок сторонних приложений. Это даже не плюс, а огромный «плюсище» — который, впрочем, рядовому пользователю не слишком и понятен. Но для знающего — просто кайф неземной.

Отсутствие истории изменения файлов и дурацкая «корзина»

Для меня это, пожалуй, главная печаль. В Dropbox можно посмотреть историю изменений файлов за довольно долгое время и, при желании, любую из версий «вернуть». У Яндекс.Диска есть только «корзина», толку от которой не так много, зато есть вред: её нужно очищать руками, поскольку она занимает место диска наряду с другими данными, а все удаляемые файлы кладутся в неё без вариантов. Написал в поддержку — может, поправят или настройку какую сделают (Dropbox, кстати, всегда «клал» на любые предложения и замечания клиентов — даже тех, кто платит). Из техподдержки Яндекс.Диска отвечают довольно резво — но, естественно, без каких-либо сроков и конкретных обещаний; зачастую шаблонами.

UPD

«Корзину» таки поправили; теперь файлы хранятся там не вечно, а в течение какого-то времени, после чего удаляются.

Клиент под Android

Клиент Яндекс.Диска под Android не оставляет в промежуточных кэшах подолгу файлы, просматриваемые с интернета, да и вообще имеет настройки по поводу очистки кэша. У Dropbox с этим печаль — всё, что ненароком просматриваешь, сохраняется в папку с кэшем и неизвестно, очищается ли вообще (кроме как вручную, конечно). В отличие от Dropbox, Яндекс.Диск не имеет возможности запаролить доступ к программе. «Паролить» приложение на мобильнике — затея не из самых умных, но я бы предпочёл наличие такой «защиты от дурака», нежели её отсутствие.

Android-клиент (по состоянию на текущий момент) просто убил невозможностью синхронизации отредактированных файлов. То есть, открываешь файл, редактируешь — а он так и остаётся отредактированным только на смартфоне, заменяясь на первоначальную версию при очистке кэша. Будет ли это исправлено — неизвестно; уже был ответ от поддержки, что «возможность действительно не реализована». Выглядит это бредом; надеюсь, справедливость вскоре восторжествует. Dropbox тут снова вне конкуренции.

Файловая БД

У Dropbox файловая база данных располагается в профиле пользователя — без вариантов. Это нереально бесит, ведь не всегда на системном разделе найдётся куча места под всякие громадные базы. Яндекс.Диск хранит БД в скрытой подпапке папки, которая указана для синхронизации, и это радует. Размер базы Яндекс.Диска примерно такой же, как и у Dropbox (при сходных объёмах информации, естественно).

core.log

В скрытой директории с базой файлов есть подробнейший лог операций, производимых клиентом Яндекс.Диска. Лог очень забавный; можно наблюдать, как при изменении одного маленького файла происходит штук 60 «телодвижений». Собственно, сразу становится понятно, почему клиент так долго думает. Надеюсь, этот лог хотя бы помогает в выпуске новых версий программы и трассировке ошибок. Ещё там можно встретить интересные имена серверов загрузки — например, sasulca453a.mail.yandex.net.

«Бонусы» синхронизации Dropbox и Яндекс.Диск

Dropbox иногда корёжил mp3-файлы. Я понимаю, что это ответственное заявление, но я видел это своими глазами. Возможно, была виновата комбинация софта на машине (антивирус, который тоже присматривает за файлами и т.п.). Некоторые mp3-файлы (единицы из тысячи) после первой синхронизации в Dropbox оказались «недозаписанными», и понял я это уже сильно после, когда от файлов остались обрезки. Я научился воспроизводить этот глюк, но причину его не понял — каким образом клиент синхронизации может «оттяпывать» кусок файла, к которому он должен прикасаться только в режиме чтения, так и осталось загадкой.

Памятуя об этом «достоинстве» у Dropbox, я заранее подготовился к тестированию Яндекс.Диска. На одной машине клиентом начал выкачивать файлы в облако (110Гб разношёрстной информации), чуть погодя запустил синхронизацию на другой машине, которая тянула файлы из облака к себе. Получившийся результат не поленился сравнить побитово из заранее сохранённой копии, которой никакая синхронизация не касалась. Эксперимент меня ошарашил.

Файлы были синхронизированы чётко — до последнего бита. Однако, из примерно 40000 файлов, несколько напрочь отсутствовали! Тут же было установлено, что это файлы определённых типов — в моём случае, file_id.diz и [что_то].gid. Первые файлы — наследие BBS, если вам это о чём-то говорит. Вторые — временные, создающиеся help-системой Windows. И если ненужность вторых не вызывает вопросов, то file_id.diz иногда содержит в себе определённую полезную информацию. Которая, как считает Яндекс.Диск, вам не понадобится.

По сути, я однозначно установил наличие у клиента Яндекс.Диск «распознавателя» файлов — которые, как он считает, пользователю будут не нужны. «Возможности» этого распознавателя неизвестны и нигде не документированы, что крайне опечаливает. Мне очень хочется узнать, где в Яндексе нашли таких одарённых программистов и проектировщиков. Решил пообщаться с техподдержкой на эту тему.

Хотелось бы узнать, какие ещё файлы игнорирует Яндекс.Диск при синхронизации? Пока что выяснил, что не синхронизирует file_id.diz и *.gid. Будут ли ещё «подарки»?

У нас действительно есть ряд форматов и файлов, которые мы исключили из синхронизации и программа их синхронизировать не будет. К таким относятся папки .svn и .git а также некоторые временные файлы различных программ. Список довольно большой.

Получается, я не могу быть уверенным в сохранности файлов, поскольку список даже не документирован. Это как минимум странно для сервиса с платными расширениями. Да и непонятно, чем руководствовался человек, добавлявший в «чёрный список» file_id.diz?

Список документирован, но он не предназначен для публичной огласки.

Вот такие секреты.

Заключение

Яндекс.Диск на данный момент — сырой сервис, не позволяющий заявить, что работать в нём комфортно — сплошные глюки, недочёты, несуразности и отсутствие важного функционала. Компенсируется всё это лишь большим «халявным» местом и дешёвыми тарифами (хотя при такой «работе» они должны быть ещё дешевле, а халявное место должно просто-таки рассыпаться всем и каждому). Очень надеюсь, что все эти недочёты будут в скором времени исправлены, иначе придётся искать новый сервис хранения файлов.

В сравнении однозначно выигрывает Dropbox (несмотря на тарифы), но и он не справляется со своей первичной функцией на 100%. То, что он покорёжил мне некоторые mp3, прощено быть никак не может и глаза на это закрыть невозможно.

 

©2014, Анатолий Савенков
опубликовано: 13.04.2014

 

Отсюда

Метки: ,


Оставить отзыв