Да тут не только у меня проблемы со скриншотами и расширениями.
https://www.dropboxforum.co...-Stable-Build-3-16-1

Напомню, что ранее мне пришлось написать костыль, программу, которая делает только одно – вырубает нахрен расширение Проводника от Дропбокса, ибо стоит соединению притормозить – красивые иконочки вешают Проводник (вместе с панелью задач и рабочим столом) нахрен.

О, новые глюки в Дропбоксе. Вы знаете о галочке «Заливать скриншоты в дропбокс»? Она делает то, что сказано – перехватывает принтскрины и сохраняет PNG файлы в каталог «Screenshots». Но если вы ожидаете, что сняв эту галочку дропбокс перестанет интересоваться принтскрином, то вы ошибаетесь. Эта галочка, как сейчас модно, отключает только сохранение. Весь остальной функционал работает, принтскрины мониторятся. Я вот, допустим, использую рабочие столы для того чтобы делать всякие вещи отдельно. Но у дропбокса авторы – немного криворучки, и дропбокс не понимает рабочие столы (хотя для скриншотов это вообще нерелевантно). Поэтому скриншоты делаются только на рабочем столе, где запущен Дропбокс, а на всех остальных картинка не попадает даже в буфер обмена. Галочка, напомню, снята. Это настолько прекрасно, что у меня нет слов. Это бест практисы от Mail.ru, когда снятие галочки «Запускать Агент при входе в систему» не удаляет Магент из автозапуска, а просто завершает его сразу же как только он запустится при логоне пользователя.
Ёбаные идиоты! >_<
Для толстолобиков: проблема возникает у полутора пользователей, но сам подход авторов дропбокса говорит о том, что им насрать на возможные конфликты, которые возникнут при работе в системе такого дуболомного кода. Это та же философия, что и майнер биткойнов, встроенный в uTorrent – а чё, пользователю жалко чё ли?

Оказалось, что клиент Дропбокса в Линуксе потребляет памяти примерно столько же, сколько и в Windows – 100-150 метров. Правда, когда была первая синхронизация, потребление взлетало до 400++, но это было раз.

Смеркалось. Dropbox продолжал отчаянные попытки выкачать четыре гига файлов с сервера, но получалось у него это плохо.

Подумалось тут. Есть такой hubic.com, т.е. ещё один дропбокс. Он не поддерживает webdav, для него нет дров для доступа из консоли linux. Как решить эту проблему? Можно попробовать решить в лоб, т.е. смотреть, какие запросы использует их сайт и отправлять такие же curl-ом. Наверняка есть куча подводных камней, и потом они обновляются. Но ведь есть же youtube-dl и его автор вовсе не дремлет.

Dropbox - пидарасы.
http://habrahabr.ru/post/267767/
Раздают место за наличие е-мыла на ВУЗовском сервере.

Уже второй раз ловлю прикол, когда прямо во время работы Дропбокс забывает все свои настройки кроме привязки к аккаунту и выборочной синхронизации. Работал, работал - БАХ! - все настройки в дефолтные. И это не выходя из программы. Правда, где-то во время этого закончилось место на диске с папкой дропбокса, но фишка в том, что сам клиент установлен на совсем другой диск, системный.

Обнаружила на машине целых два сервиса, которые занимаются обновлением дропбокса. ДВА, КАРЛ! Один екзешник, два задания в планировщике и два сервиса! Они ебанулись там совсем?

yes, new installation 3.6.9 causes error 0x800b0109
using 3.6.7 - and ignoring the "cant sync" message-window (minimize it)
and everything works.
there is something strange in the neighbourhood ;)

https://www.dropboxforum.co...ty_comment_203547955
К сожалению, охотники за привидениями тут не помогут =_=

Итог дня: автообновление дропбокса на трёх машинах - тройной фэйл.

Dropbox ведёт себя неадекватно. Постоянно заменяет мой ярлык на рабочем столе, ведущий к папке, на свой, ведущий к екзешнику, открывающему, блеать, папку. Кроме того, он зачем-то упорно сбрасывает атрибут read-only с папки, в результате чего красивая иконка не отображается. Хочется крови.

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

Поправка. Обновление проверяется каждый час. Вдруг опять какие иконки для макосси добавят!

Оказывается, Dropbox теперь обновляется не только отдельной программой, но ещё и стартует её через планировщик заданий, ге у него создано аж два задания: одно запускается каждый день ночью, а другое - при логоне. При чём интересно, что на одном компьютере они стартуют от лица пользователя, а на другом - от лица системы.

Не знаю, что натворили в новой версии дропбокса, но у меня постоянно запускается DropboxUpdate.exe, хочет завершать работу системы и ломится куда-то в интернет. Что это за хрень?

Странно. Захожу на сайте дропбокса в один из каталогов. В у меня там папки вида "~Byaka". В списке папок она выводится как "---Byaka". Захожу в неё. Выше списка файлов и папок показывается текущий путь, и имя папки там выводится как "~Byaka". Что за фигня?

Пошла на форум, посмотреть, что там обновили в Дропбоксе такого, что он базу обновлял. Оказалось, что подправили интерфейс. Мда. Но! Сайт сообщил, что я изменила более пятисот файлов, и не нужна ли мне помощь. Пошла смотреть, что за файлы изменились, пока я была в дороге. Оказалось, что каждое изменение лога PuTTY он считает за отдельный файл, а так как у меня сейчас идёт активная работа, в Events так и написано: "Изменился Byaka.LOG и ещё 10 файлов". По ссылке сообщается, что изменился Byaka.LOG, потом ещё Byaka.LOG, ещё Byaka.LOG и Byaka.LOG со всеми остальными Byaka.LOG. Короче, конфузящие сообщения в логе (в подробностях такая форма подачи вполне объяснима), похоже, сбила с толку и самих разработчиков.

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

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