• DropBox программы Есть такой текстовый редактор Dana, японский, но относительно старый, давно не обновлялся. Для хранения "закладок" в тексте, он создаёт специальный двоичный файл с номерами строк и сохраняет его рядом с самим текстовым файлом. Например, для файла Diary.TXT Дана создаёт файл Diary.TXT.#marks# и обновляет его по мере необходимости.
    Посты в дайрик я пишу в Дане — у меня даже есть скрипт для облегчения вставки BB кодов и прочего (сам скрипт можно найти на моём сайте.). Поэтому я не использую для постов другие редакторы — лень портировать функционал туда. Так вот, у меня есть специальная папка в дропбоксе, в который эти файлы лежат — туда я пишу на работе, на одной домашней машине, на другой, и всё синхронизируется.
    Некоторое время назад у меня нарисовалась проблема. Периодически, когда я писала новый пост и сохраняла текстовый файл с ним, сам текстовый файл успешно заливался на сервер, а вот сопутствующий файл мог висеть в статусе "Uploading" долго, по нескольку часов. Бывало, я сразу не замечала, и он так по полдня грузился. Потом происходило чудо, либо файл изменялся (становился больше, например), либо я его вообще удаляла, и синхронизация продолжалась в штатном режиме.
    Файл не представляет из себя ничего особенного, весит не больше килобайта, содержит в основном нули, антивирусом не детектируется. Так что причина такого поведения мне была непонятна.
    Сегодня случилось это вновь. Файл весом 50 байт завис на два часа, в то время как все остальные прекрасно гуляли туда-сюда. Тоесть я кидаю двадцать метров фотографий, попутно с другой машины прилетает DOC файл на полтора метра, и всё отлично, а в это время 50 кило отчаянно пытаются улететь на сервер.
    Я решила посмотреть, что происходит. Открыла файл в двоичном редакторе (который, к слову, тоже в дропбоксе лежит), посмотрела — ничего необычного. Сохранила, чтобы обновилось время изменения — ничего не поменялось.
    Потом меня посетила догадка. Вдруг это как-то связано с LAN Sync? Пошла на соседнюю машину, посмотрела логи файрволла, ничего интересного не нашла, вырубила его. Не помогло.
    Тут я вдруг заметила, что висят уже два файла. К двоичному файлу присоединился текстовый конфиг двоичного редактора. Я была удивлена, ибо проблемы всегда были только с #marks# файлами.
    Надо отметить, что я встречала проблему только на одной машине. Помнится, ранее я в подобных условиях отредактировала текстовый файл на другой машине, заставив измениться #marks# файл, и тот залился без проблем, а тот, что висел на первой машине, превратился в конфликтную копию. Дропбокс его переименовал, но загрузить по прежнему не смог.
    Тогда я взяла и по сети перекинула #marks# файл на соседнюю машину в ту же папку. Клиент на соседней машине взялся за дело, и тоже не смог. В итоге я получила две машины с одним и тем же файлом, не пролезающим на сервер.
    Я пыталась перезапускать клиент, но это не помогло. Каждый раз после индексации он начинал выгружать #marks# файл и не справлялся.
    // Продолжение в камментах...

Replies (3)

  • @Linda-chan, Тогда я призвала на помощь товарища, скинув ему сторонними методами #marks# файл. Тот поставил свежую версию дропбокса, подключился, закинул файл в папку, и тот сию же минуту ушёл.
    В задумчивости я посмотрела на клиент дропбокса и внезапно обнаружила, что #marks# файл у меня тоже ушёл на сервер. Теперь висел только конфиг. Я немного офигела и скинула товарищу ещё и конфиг. Тот закинул его в папку, и клиент на моей машине отрапортовал, что все файлы синхронизированы.
    Иными словами, где-то там, в левом аккаунте, зарегистрированном на левую почту появился файл, такой же как у меня, и мой файл немедленно оказался синхронизирован. Это не какой-то стандартный файл, его содержимое вполне уникально, но система сообразила, что есть сходства и упростила себе работу.
    Напомню, что где-то там, в туре по дропбоксу на официальном сайте говорится (или говорилось), что все файлы шифруются на сервере, ключ есть только у пользователя, и никакой админ не может туда заглянуть. Понятно, что это всё враньё, но всёже.
    На самом деле то, что я описала, было известно мне и ранее. Пару лет назад какиры обнаружили, что есть какой-то API вызов или ещё какой люк, а у каждого файла есть хэш, который однозначно определяет файл в системе. Где бы он ни лежал, его можно вытащить, зная хэш. Даже файлообменную сеть сделали. Юзер заливает кино к себе в дропбокс, получает хэш, выкладывает его в интернетах. Другие юзеры берут хэш, вбивают куда следует, и кино тут же материализуется у них в папках. Потом фича сломалась, лавочку прикрыли. Как оказалось, закрыли люк, но система с хэшами как была, так и осталась.
    Собственно, за последнюю пару недель это второй случай, когда я лично наблюдаю весьма сомнительное поведение данного продукта. Ранее по непонятным причинам клиент шарил по всяким папкам на диске, и я лично видела это. Теперь я своими глазами увидела, что личная папка не столь уж личная.
    Наверняка есть какое-то объяснение. Глючащее расширение оболочки (файлы, к которым обращался клиент, так или иначе появлялись в проводнике при этом), оптимизация с целью снизить нагрузку на сервер и каналы. Но... Учитывая героическое молчание официальных представителей, это всё как-то напрягает.
    К слову, у товарища, помогшего мне в исследовании, клиент дропбокса заглядывал в папку OneDrive. А ещё, сразу же после установки, он перехватил ввод с клавиатуры, но где-то глюкнул и заблокировал любой ввод кроме мыши. Зачем дропбоксу клавиатура?
    Короче, пора мазать лыжи.
  • @Linda-chan, хеши само собой продолжили работать ) личная папка остается личной, т.к. просто обладание хешом теперь не даёт доступа к файлу, нужно еще и сам файл получить, но хранятся они всё так же сплющиванием в единую копию. но они ж immutable — изменишь файл — получишь новую копию на сервере
  • @SunChaser, Ну, оптимизация, само собой. Но простор для фатального глюка имеется.