Как работает синхронизация яндекс диска и телефона. «Яндекс.Диск»: синхронизация — это модно! Что произойдет, если я удалю программу или переустановлю операционную систему

Совпадает с данными на сервере благодаря синхронизации. Соответственно, если она не работает, то теряется смысл использования программной версии хранилища. Поэтому исправлением ситуации нужно заняться как можно скорее.

Способ решения проблемы будет зависеть от причины её возникновения. В любом из случаев разобраться, почему Яндекс Диск не синхронизируется, можно самостоятельно, не потратив много времени.

Причина 1: Синхронизация не включена

Для начала самым очевидным будет проверить, включена ли синхронизация в программе. Для этого кликните по значку Яндекс Диска и вверху окна узнайте о её состоянии. Для включения нажмите соответствующую кнопку.

Причина 2: Неполадки интернет-соединения

Если в окне программы, Вы увидите сообщение «Ошибка соединения» , значит, логично будет проверить, подключен ли компьютер к Интернету.

Для проверки интернет-соединения нажмите на значок «Сеть» . При необходимости подключитесь к рабочей сети.

Обратите также внимание на состояние текущего подключения. Здесь должен быть статус «Доступ к Интернету» . В противном случае нужно обращаться к провайдеру, который обязан решить проблему с подключением.

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

Причина 3: Нет места в хранилище

Возможно, на Вашем Яндекс Диске попросту закончилось место, и новым файлам некуда загружаться. Чтобы это проверить, перейдите на страницу «облака» и посмотрите на шкалу его наполненности. Она расположена внизу боковой колонки.

Для работы синхронизации хранилище нужно очистить или расширить .

Причина 4: Синхронизация блокируется антивирусом

В редких случаях антивирусная программа может блокировать работу синхронизации Яндекс Диска. Попробуйте ненадолго отключить её и понаблюдать результат.

Причина 5: Не синхронизируются отдельные файлы

Некоторые файлы могут не синхронизироваться потому что:

• вес этих файлов слишком большой, чтобы разместить их в хранилище;
• эти файлы используются другими программами.

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

На заметку: файлы объёмом более 10 Гб на Яндекс Диск загрузить вообще нельзя.

Причина 6: Блокировка Яндекса на Украине

В связи с недавними нововведениями в законодательстве Украины, Яндекс и все его сервисы перестали быть доступными для пользователей этой страны. Работа синхронизации Яндекс Диска также под вопросом, т.к. обмен данными происходит с серверами Яндекса. Специалисты этой компания делают всё возможное для решения проблемы, но пока украинцы вынуждены искать пути обхода блокировки самостоятельно.

Возобновить работу синхронизации можно попытаться, используя подключение по технологии VPN. Но в данном случае речь не идёт о многочисленных расширениях для браузеров — Вам понадобится отдельное приложение VPN, чтобы шифровались подключения всех приложений, в том числе и Яндекс Диска.

Сообщение об ошибке

Если не один из приведённых методов не помогает, то правильно будет сообщить о проблеме разработчикам. Для этого нажмите на значок настроек, наведите курсор на пункт «Справка» и выберите «Сообщить в Яндекс об ошибке» .

Вскорости Вы получите ответ от службы поддержки по Вашей проблеме.

Для своевременного изменения данных в хранилище должна быть включена синхронизация в программе Яндекс Диск. Для её работы компьютер должен быть подключён к Интернету, в «облаке» должно быть достаточно места для новых файлов, а сами файлы не должны быть открыты в других программах. Если причину проблем с синхронизацией не удалось выяснить, обратитесь в службу поддержки Яндекса.

В последнее время все большую популярность набирают сервисы облачного хранения данных, такие как Яндекс.Диск, Google Drive и т.д и т.п. Они позволяют Вам подстраховаться от потери важных данных, таких как документы фотографии и др. В принципе это удобно, за исключением одного момента – программное обеспечение сервиса создаёт на компьютере свою папку, с которой осуществляет синхронизацию облачный сервис, т. е. чтобы отправить какие-то данные в “облако” нужно скопировать их в эту папку. Это неудобно при больших объемах данных: так если у вас, к примеру, 300 Гб фотографий, то для синхронизации их нужно выделить и скопировать в папку сервиса (а копирование такого объема явно не для слабонервных), и это процесс нужно повторять при обновлении данных. Но нашлось решение проблемы – символическая ссылка.

Символическая (символьная) ссылка - специальный файл в файловой системе, для которого не формируются никакие данные, кроме одной текстовой строки с указателем. Эта строка трактуется как путь к файлу, который должен быть открыт при попытке обратиться к данной ссылке (файлу). Символьная ссылка занимает ровно столько места в файловой системе, сколько требуется для записи её содержимого.

Символьные ссылки используются для более удобной организации структуры файлов на компьютере, так как позволяют для одного файла или каталога иметь несколько имён и различных атрибутов, а также свободны от некоторых ограничений, присущих жёстким ссылкам (последние действуют только в пределах одной файловой системы (одного раздела) и не могут ссылаться на каталоги).

Это по материалам Wikipedia, а если “по-русски”, то все что у вас в каталоге, на который указывает ссылка, то и в целевом каталоге. Сама символьная ссылка широко используется на Linux системах, но есть возможность создать ее и в системе Windows.

Создать ссылку можно с помощью командной строки, но гораздо-гораздо проще с помощью утилиты Link Shell Extension , которая умеет создавать требуемый тип ссылки.

Рассматривать данный метод мы будем на примере сервиса Яндекс.Диск.

И так. Для начала необходима регистрация в системе Яндекс. Далее переходим на страницу Яндекс.Диск , скачиваем дистрибутив ПО Яндекс.Диск на компьютер и устанавливаем его. Появиться иконка в виде летающей тарелки с зеленой галочкой или синим кружочком со стрелочками на Панели задач возле часов.

Также будет создана папка Яндекс.Диск на компьютере в указанном вами месте.

Затем скачиваем утилиту Link Shell Extension , устанавливаем ее, перезагружаем компьютер и в контекстном меню, вызываемом нажатием правой кнопки мыши, у нас появляются новая строка “Запомнить источник ссылки”.

Чтобы синхронизировать папку с “облаком”, находим ее на Компьютере, нажимаем по ней правой кнопкой мыши и выбираем “Запомнить источник ссылки”.

После всего этого переходим в папку Яндекс.Диск, нажимаем правой кнопкой мыши и выбираем “Поместить как -> Символическую ссылку”

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

Принцип синхронизации заключается в следующем: при совершении действий с файлами (редактирование, копирование или удаление) изменения происходят и в облаке.

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

При одновременной загрузке с разных устройств файлов с одинаковыми именами, Яндекс Диск присвоит им порядковый номер (file.exe, file(2).exe и т.д.).

Индикация процесса синхронизации в системном трее:

Такие же значки появляются у всех файлов и папок в каталоге Диска.

Скорость, с которой происходит синхронизация данных на Яндекс диске можно узнать, наведя курсор на значок приложения в трее.

Может показаться странным, что, к примеру архив весом 300 МБ, закачался на Диск за несколько секунд. Ничего странного, просто программа определяет, какие фрагменты файла были изменены и синхронизирует только их, а не весь архив (документ) целиком.

Это очень удобно, если на Диске хранятся файлы какого-либо текущего проекта. Редактирование документов прямо в папке Диска экономит трафик и время.

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

Файлы в папку с отключенной синхронизацией закачиваются либо на странице сервиса, либо через меню настроек .

Разумеется, в приложении присутствует функция полного отключения синхронизации с облачным хранилищем.

Вывод: процесс синхронизации позволяет вносить изменения в документы сразу на всех устройствах, подключенных с помощью приложения Яндекс Диск к одному аккаунту. Сделано это для экономии времени и нервов пользователей. Синхронизация избавляет нас от необходимости постоянно скачивать и закачивать редактируемые файлы на Диск.

Разработка веб-сайтов ,

Алгоритмы

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

В этом посте я расскажу, почему так получилось: чего мы не смогли предвидеть, когда придумывали первую версию ПО Яндекс.Диска, и как создавали новую.

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

Почему это не так просто, как кажется на первый взгляд?

Теоретически задача может показаться достаточно простой, но в реальности мы сталкиваемся с разными сложными ситуациями. Например, человек переименовал папку на своем компьютере, мы это детектировали и послали команду на бекенд. Однако никто из пользователей не ждет, пока бекенд подтвердит успешность переименования. Человек сразу открывает свою локально переименованную папку, создает в ней подпапку, и, к примеру, переносит в нее часть файлов. Мы попали в ситуацию, в которой невозможно сразу выполнить все необходимые операции синхронизации в облаке. Сначала надо дождаться завершения первой операции и только потом можно продолжать.

Ситуация может стать еще сложнее, если с одним аккаунтом одновременно работают несколько пользователей или у них есть общая папка. А это случается достаточно часто в организациях, использующих Яндекс.Диск. Представьте себе, что в предыдущем примере в тот момент, когда мы получили от бекенда подтверждение первого переименования, другой пользователь берет и переименовывает эту папку еще раз. В этом случае опять нельзя сразу выполнить действия, которые уже совершил первый пользователь у себя на компьютере. Папка, в которой он работал локально, на бекенде в это время уже называется по-другому.

Бывают случаи, когда файл на компьютере пользователя нельзя назвать так же, как он называется в облаке. Это может произойти, если в имени есть символ, который не может использоваться локальной файловой системой, или в том случае, когда пользователя приглашают в общую папку, а у него есть своя папка с таким именем. В таких случаях нам приходится использовать локальные псевдонимы и отслеживать их связь с объектами в облаке.

Прошлая версия алгоритма

В прошлой версии десктопного ПО Яндекс.Диска для поиска изменений использовался алгоритм сравнения деревьев. Любое другое решение на тот момент не позволяло реализовать поиск перемещений и переименований, так как бэкэнд не имел уникальных идентификаторов объектов.

В этой версии алгоритма мы использовали три основных дерева: локальное (Local Index), облачное (Remote Index) и последнее синхронизированное (Stable Index). Кроме этого, чтобы предотвратить повторную генерацию уже поставленных в очередь операций синхронизации, использовались ещё два вспомогательных дерева: локальное ожидаемое и облачное ожидаемое (Expected Remote Index и Expected Local Index). В этих вспомогательных деревьях хранилось ожидаемое состояние локальной файловой системы и облака, после выполнения всех операций синхронизации, которые уже поставлены в очередь.

Процедура сравнения деревьев в старом алгоритме выглядела следующим образом:

1. Если локальное ожидаемое дерево и облачное ожидаемое дерево пусты, инициализируем их, копируя последнее синхронизированное дерево;
2. Сравниваем локальное дерево с облачным ожидаемым и по результатам сравнения отдельных узлов добавляем в очередь операции синхронизации в облаке (создание коллекций, передача файлов в облако, перемещение и удаление в облаке);
3. Для всех операций, которые поставлены в очередь на предыдущем шаге, фиксируем их будущий эффект в ожидаемом облачном дереве;
4. Сравниваем облачное дерево с локальным ожидаемым и по результатам сравнения отдельных узлов добавляем в очередь операции синхронизации с локальной файловой системой (создание директорий, скачивание файлов из облака, перемещение и удаление локальных файлов и директорий);
5. Для всех операций, которые поставлены в очередь на предыдущем шаге, фиксируем их будущий эффект в ожидаемом локальном дереве;
6. Если в очередь попадают одновременные операции с одним и тем же файлом или директорией (например, передача файла в облако и скачивание этого же файла из облака), то фиксируем конфликт - файл изменился в двух местах;
7. После того, как операция синхронизации выполнена в облаке или с локальной файловой системой, заносим её результат в последнее синхронизированное дерево;
8. Когда очередь операций синхронизации становится пустой, удаляем локальное ожидаемое и облачное ожидаемое дерево. Синхронизация закончена, и они нам больше не понадобятся.

Почему нам пришлось придумывать новый алгоритм

Главными проблемами алгоритма сравнения деревьев стали большое потребление памяти и необходимость сравнения деревьев целиком даже при небольших изменениях, что приводило к большой нагрузке на процессор. Во время обработки изменений даже одного файла использование оперативной памяти возрастало примерно на 35%. Допустим, у пользователя было 20 000 файлов. Тогда при простом переименовании одного файла размером 10Кб потребление памяти вырастало скачкообразно - со 116Мб до 167МБ.

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

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

К этому времени на бекенде появились id объектов, с помощью которых можно было более эффективно решить задачу обнаружения перемещений - ранее мы использовали пути.

Новый алгоритм

Мы решили изменить структуру хранения данных и заменить три дерева (Local Index, Remote Index, Stable Index) на одно, что должно было привести к снижению избыточности в главной структуре данных. Из-за того что ключом в дереве является путь к элементу файловой системы, в результате объединения значительно сократился объем используемой оперативной памяти.

Еще мы отказались от использования вспомогательных деревьев во время синхронизации, потому что каждый элемент дерева в новой версии хранит все нужные данные. Это изменение структуры сильно упростило отладку кода.

Так как мы понимали, что это серьезное изменение, то создали прототип, подтвердивший эффективность нового решения. Рассмотрим на примере, как меняются данные в дереве во время синхронизации нового файла.

1. После того как пользователь добавил в папку Диска новый файл, программа обнаружила его и добавила в дерево новый элемент. У этого элемента известно только одно состояние – local. Так как stable и remote состояния отсутствуют, память под них не выделяется;
2. Программа выполняет upload файла. Из облака приходит push, подтверждающий появление нового файла, и в дерево добавляется remote состояние;
3. Состояния local и remote сравниваются. Так как они совпадают, добавляется stable состояние;
4. Состояния local и remote удаляются. Они больше не нужны, так как вся информация есть в stable.

На этом примере видно, что в новом алгоритме синхронизации обрабатываются только те элементы и события, данные об изменениях в которых были получены от файловой системы или облака, а не всё дерево целиком, как это было ранее. При необходимости будут обработаны родительские или дочерние узлы (например, в случае перемещения папки).

Другие улучшения

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

Яндекс.Диск использует дайджесты sha256 и MD5 для проверки целостности файлов, обнаружения изменившихся фрагментов и дедупликации файлов на бекенде. Так как эта задача сильно нагружает CPU, в новой версии реализация расчетов дайджеста была существенно оптимизирована. Скорость получения дайджеста файла увеличена примерно в два раза.

Цифры

Синхронизация уникальных 20000 файлов по 10Кб

Вычисление дайджестов уникальных 20000 файлов по 10кб (индексация)

Запуск с 20000 синхронизированных файлов по 10Кб

Upload 1Gb. Соединение Wi-Fi 10 МБит
Время, сек

Что получилось

Из примеров видно, что новая версия ПО Яндекс.Диска использует примерно в 3 раза меньше оперативной памяти и примерно в 2 раза меньше нагружает CPU. Обработка мелких изменений не приводит к увеличению объема используемой памяти.

В результате проделанных изменений существенно увеличилось количество файлов, с которым без проблем справляется программа. В версии для Windows – 300 000, а на Mac OS X - 900 000 файлов.