Comments 150
Давно дропбокс не пользуюсь, но какие-то старые проекты и бэкапы там все еще лежат. Спасибо, что напомнили проверить
Сто лет не было Dropquest. Видимо их всё устраивает. Ну хоть старые бонусные Гб не отбирают у бесплатных аккаунтов.
У меня честно накрученные 16GB + ещё по акциям насобирал. В итоге - 29GB из которых 5 занято. Использую как буфер между пк и смрадфоном. Сливаются фотки которые потом пк подтягивает.
SyncThing в помощь. Будет сливаться напрямую, без участия далёких облаков.
Syncthing кстати еще относительно нормально работает в ситуации - "десятки тысяч каталогов, в них подкаталоги и файлы, и 150 Gb всего и это надо синхронизировать, включая обновления, в том числе на мобилки, при этом часть файлов могут быть открыты(в этом случае надо просто их не трогать пока)". Dropbox такое переносит не очень (OneDrive правда еще хуже это сносит)
Забирают. В том плане, что имеющиеся файлы там еще хранятся, но вот новые уже не загрузить, пока не снизишь размер до "правильного" лимита
А как забирают? Я как накрутил себе году в 12-м 24 гб, так и использую по сей день. Не пропало ни гига
Не забирают пока. Был косяк с удалением, у меня по какой-то причине rclone не почистил при синхронизации, и нельзя было загрузить ничего нового. Вылечилось удалением ненужного ниже лимита, и всё снова ок.
На сколько помню позиция была типа «дропбокс не для хранения исходников». И в принципе я с этим согласен.
Если они начнут делать вот это вот все, им мозги ложечкой проковыряют, как это любят делать ИТшники для своих утилит. И нафиг это кому надо в общей массе.
Dropbox для хранения файлов. Исходники тоже файлы.
Более того, даже в рамках дискуссии по обсуждаемой идее компания довольно быстро признала, что возможность исключать файлы из синхронизации людям нужна. В статье всё это написано. Написано даже, что нужно это не только программистам с их злополучными исходниками.
Есть опыт других компаний, которые возможность игнорирования файлов предоставляют. И никто мозги ложечкой им не ест.
Я уже не говорю о том, что (повторяю написанное в статье) Dropbox сам предоставил площадку для публикации идей и вот у них на руках самая желаемая фича, и они её игнорируют.
Тот факт, что дропбокс предоставил возможность рекомендовать идеи совсем не значит, что если идея собирает много голосов - она ДОЛЖНА быть реализована.
Дропбокс никогда не позиционировал себя как решение для удобного(!) хранения исходников. Никто не запрещает их вам там хранить, конечно, как кучу файлов. Но вы же не просите производителя ножей сделать их безопасными для детей потому что дети могут ими воспользоваться вскрывая замок и пораниться, правда?
ну короче, проблема высосана из пальца на уровне «абсолютно». Вы попросили посудомойку сделать минет, она отказалась, вы злитесь что «в брошюре написано пожелания принимаются и мое мнение важно!».
давайте без программистов. фотография. мне нужно хранить оригиналы отобранных фото (RAW), обработанные выходные жпеги и собственно всё. входящая папка с 30-50-150Гб равок и промежуточные папки для редактирования (кто пользуется Capture One - поймет) нахер не нужны ни в какой синхронизации. dropbox я, правда, тоже не пользуюсь, но вот готовый вариант, где нужно И дохера места И игнорирование определенных путей.
Что за промежуточные папки для редактирования? Я как пользователь C1 не понимаю )
селекты, мусорка.
Все равно не понимаю.
Импортируем папку в c1, если там делаем отбор/отбраковку, то это не трогает файлы на диске. Может быть у вас как то все настроено по другому, но, ИМХО, С1 не должен трогать файлы с равами вообще. Пишет спокойно в свою базу данных о том что фотографию забраковали и не трогает ее на диске.
Или мы о разных вещах говорим?
я ж говорю - у меня файловый режим, всех этих даз банных я наелся еще с лайтрумом, а значит в каждой папке, куда ходит C1 - есть подпапка CaptureOne, в которой по 3 файла метаданных на 1 картинку.
у меня типичная структура:
[съемка]:
_in
_out
_sel
_trash
на облако лить надо только _out (причем без внутренного CaptureOne) и _sel, 2 других должны быть чисто локальными.
Хм, мой процесс работы с C1 предполагает
1) работаем с файлами RAW на диске
2) после обработки папки - делаем экспорт в JPG в архив для просмотра
3) после обработки файла - скидываем все без кэша в архив
И вот результат 2 и 3 летят в архив и в облако, реализуется простеньким rsync.
Но, конечно, Dropbox - не лучший вариант для хранения фотографий (дорого и неудобно).
ну полностью процесс у меня сильно длиннее:
1. скидываем флешки на комп
2. запускаем exiftool, переименовываем их все под shutter count
3. запускам FastRawViewer, листаем фотки кнопкой delete
4. выжившее идет в _in
5. capture one, разглядывание, обработка и перемещение в _sel
6. capture one, второй круг уже по _sel, ненужное - в _trash, экспорт в _out
7. Lightroom на _out - второй проход шумодава, подписи.
8. полный экспорт - заказчику, остальное подчищается и _sel _out уходят на хранение на другой комп, _in _trash подчищаются через несколько дней - на всякий случай, вдруг какой-то важный кадр проморгал.
Ваша задача прекрасно решается хардлинком нужных папок в папку которую уже синхронизирует дропбокс.
А могла бы прекрасно решаться декларативной конфигурацией по исключению ненужных папок, без операций с файловой системой.
то есть мне на каждую съемку городить дополнительную пачку хардлинков и следить чтоб они не развалились?
Все конечно решается. Но нужно чтобы было удобно. Иначе пользоваатели будут уходить туда, где смогли сделать удобно
Занимаюсь фото правда не в огромном масштабе, тоже не понял промежуточные папки. В том же лайтруме можно все в 3 клика отсеять и оценок фоткам наставить, а потом экспортировать только то что нужно. Все настройки лежат в маленьком файле lrcatalog, фотки в исходном виде в папке, во время редактирования их никто не копирует.
это у вас этот самый lrcatalog не разваливался никогда. пока я с этого угребища не ушел, у меня и sidecar xmp включены были и вся сортировка шла строго по физическим папкам, хватило один разок потерять ~ годовой каталог на несколько сот гигов исходников.
А зачем годовой каталог таскать? 1 проект = 1 каталог. Фото у меня на NAS, можно включить бекапы/версии, в таком случае даже если сломается то можно откатиться. Фото руками не копируются, автоматом скриптом улетают на нас как только флешка в пк появляется. Сеть 10гбит позволяет особо не думать о переносе на основной пк, и работать с фото напрямую на NAS.
Немного удивлен почитав ваши комментарии. Работа есть а пайплайн муторный и мануальный.
А каким образом у вас идет нейминг папки со съёмки, или все хранится в общей куче?
В моем случае все в куче так как смысла от разделения нет (На эту папку натравил Immich, таким образом у меня еще и поиск по обьектам и людям работает, а так же красивый и ультра быстрый веб гуи). Но ничего не мешает оставить скрипт авто копирования на NAS в папку аля "разобрать", откуда собственно фото пойдут по папкам разных проектов. Так как это все в рамках NAS, то (в моем случае truenas) не глупый, и при переносе файов поменяет их адреса но ничего никуда копировать физически не будет, тысячи файлов улетают за секунду. Собственно в папке проекта навести красоту с lrcatalog файлами и папками типа RawContent и DevelopedImages.
и что из этого мне вот прям надо автоматизировать? там самый долгий шаг -отсмотреть снятое, я с концерта и 4к кадров притащить могу (на выходе - 15-30шт на показ, плюс еще несколько десятков "для себя" или странных версий), остальные шаги просто какие-то крохи занимают.
Вы создали продукт для клиентов. Клиенты хотят фичу, которая явно увеличит популярность продукта. Какой смысл не делать запрашиваемую фичу и терять прибыль?
(Тем более, что реализация фичи не затребует много ресурсов. Там буквально пол-сотни строк кода написать в клиент и всё).
> которая явно увеличит популярность продукта.
Для кого явно? Ответ на вопрос не так прост, как кажется.
Ну и про "две строчки" "пол сотни строк" - это со стороны кажется просто, а на практике там может быть гораздо больше сложностей. Не будучи лично знакомым с кодовой базой продукта давать оценки сложности - дело такое себе)
Для кого явно? Ответ на вопрос не так прост, как кажется.
На сегодняшний день у виновника торжества 1300+ голосов, 600000+ просмотров и свыше 1000 комментариев
Вот для этих 1300+ человек (проголосовавших) это реально важно. А сколько ещё людей сочтут эту фичу весьма полезной, но не голосовали?
Популярность продукта - это число людей, которые им пользуются. Появление этой фичи не гарантирует, что им начнут пользоваться больше людей)
Ну и в реальности обычно из числа людей, которые просят какую-то фичу реально пользоваться ей будет... от продукта зависит, но в среднем, по личному опыту - от 10 до 50%. При этом отсутствие фичи не мешает им пользоваться продуктом, потому что для многих из них она третьестепенная. Будет - классно, не будет - ну и пофиг.
Считаю пример с посудомойкой совершенно некорректным. Сервисы по облачному хранению данных оперируют файлами, поэтому вполне легитимно просить от них неких "улучшений" этих самых операций по обработке файлов. А отсеивать ненужные файлы (пользователь сам решит, что нужно, а что нет), как по мне, само собой напрашивается.
Но, разумеется, ваше мнение может не сходиться с мнением тысячи людей, желающих эту "высосанную из пальца" фичу.
GitLab CE, GitHub - ваш выбор. Версионирование, коммиты, Actions / CI/CD.
Вы можете настроить в гитхабе Actions так, что при пуше автоматически собирается новая версия вашей утилиты и кладётся в releases. Это ж круто. Можете сделать репу публичной и давать утилиту знакомым, им не нужно будет собирать из исходников.
С версионированием (и гитлабом/хабом) плюсов больше чем с дропбоксом. Я бы на вашем месте сделал выбор в пользу гитхаба, а не ждал пока облака прикрутят фичу игнорирования файлов.
Но ведь я про версионирование вообще не говорил. Лично я важные проекты, разумеется, веду в GitHub. Но ничего не должно мне запрещать хранить эти проекты ещё и в Dropbox. Вообще в статье целый абзац есть касательно того, о чём вы говорите. Но пару моментов повторю:
У меня много утилит, которые я делаю просто, чтобы разово что-то проверить или сгенерировать. Я не хочу класть их в GitHub, создавать репозиторий, выполнять какие-то команды. Мне нужен просто бэкап этих проектов, чтобы я мог на другом компьютере их сразу же поиметь при синхронизации с облаком и всё.
Обсуждаемая в статье фича нужна не только программистам (в статье про это написано).
А как оно устроено у меня, можно почитать в статье Создание .NET библиотеки от А до Я. Там и GitHub и пайплайны и релизы и документация и чего только нет. Только это не должно мне запрещать использовать Dropbox простым способом: хранить там проект и не отправлять временные файлы в облако.
Git — это параллельный инструмент облачному хранению файлов, и одно другое не заменяет.
Есть, например, два ПК. Код одного проекта пишется и там, и там. Переключение между ПК происходит в течение дня. В случае использования Git пришлось бы в течение дня делать много комитов + пуш нерабочего кода для синхронизации между ПК.
Поэтому папка с проектом лежит в облачном хранилище и синхронизируется автоматически между всеми ПК. В проекте, естественно, используется git (Github с CI/CD), но комиты + пуш в удаленный репозиторий делаются только при завершении работы над фичей.
Проблема в том, что нужно не забывать каждые 5 минут делать коммит и пуш. Придется делать какую-то автоматизацию, которая будет через заданные промежутки делать коммит и пуш в нужную ветку, плюс проверять, есть ли вообще изменения. В общем, это не такой простой процесс. А с облачными хранилищами всё просто — поставил клиента и забыл.
Ещё IDE может работать с исходниками на удалённой машине, например, по SSH, ничего синхронизировать не надо
Другой ПК выключен, не имеет белого IP. В этом варианте тогда уже проще пользоваться облачными IDE (тем же GitHub Codespaces).
Зачем? Перед тем, как идти за другой комп, сделайте коммит.
Пробовал, забываю. Допустим код пишется 30 минут, тут поступил звонок, срочно переключился на другую задачу, далее нужно ехать куда то срочно и т.п. Постоянно есть отвлекающие факторы. Да лишние это действия. Все что можно автоматизировать - должно быть автоматизировано.
У меня проблема бала только с проектами на Rust, т.к. там временных файлов на несколько гигабайт создается. Но проблема решилась путем вынесения этих файлов в директорию которая не синхронизируются (в cargo есть такая настройка)
Положите в облако или на ваш "сервер" код и подключайте к нему десктопную IDE. Современные IDE давно так умеют
В этом варианте на удаленный VPS ставится агент IDE и работа ведется через ssh. При этом сборка проекта происходит на удаленной машине. Нужно арендовывать другую VPS с хорошим процессором, что бы собирать проекты на Java, Rust, C++ т.к. там куча зависимостей которые компилятся и это очень долго на слабых ЦП.
Допустим код пишется 30 минут, тут поступил звонок...вы уехали, а какой-нибудь скрипт в фоне на этом проекте остался. И он что-то делает с ФС постоянно, а дропбокс это все синхронизирует и в итоге вы не можете работать на втором компьютере.
Ситуации можно придумать в обе стороны.
Зачем? Перед тем, как идти за другой комп, сделайте коммит.
Зачем делать лишние действия, если можно сделать так, чтобы их не делать?
Я не разработчик, так, пару раз ковырял микроконтроллеры, да несколько раз web-проектики стряпал, и то - каждый раз разворачивал GIT и прописывал в IDE синхронизацию при сохранении (ладно, по началу прописывал синхронизацию по ssh с "разработческим" web-сервером) - не представляю, в чём могут быть трудности. Я.Диск/OneDrive/GDrive тоже использую, но по совершенно иным сценариям.
Оно так в теории. На практике то, что говорят выше не лишено смысла.
Я вот тоже облаком для кода не пользуюсь, работаю на проекте и все лежит в репе. При пуше в ветку запускается CI и около 20 минут собирает проект. Сервер не бесконечно мощный и количество ранеров CI ограничено. Соответственно каждый пуш забирает ресурсы сервера и если пушит кто-то еще - все это выстраивается в очередь. Можно конечно настроить CI собирать только мастер и dev ветки, допустим, но тогда перед мержами нужно будет руками запускать CI для нужного коммита. Короче говоря в каждом случае нет "плохо" и "хорошо", есть нюансы. И если кому-то хотелось бы синхронизироваться через облако - возможно в их случае это действительно удобно. У меня тоже бывало что сидишь за стационарным компом, потом жена просит съездить куда-то с ней (и там нужно будет подождать минут 40). Хотелось бы просто взять ноут и продолжить работать с того же места. С репой нужно закоммитить состояние, убедиться что како-нибудь забытый stash не потеряется (в смысле не останется дома, т.к. туда что-то временно запихнул), короче много вариантов )
Зачем оно запускаеся, если не нужно?
Перед мержем в другие ветки все же нужно, чтобы собралось и тесты прошли. Я об этом писал - это просто пример. Здесь что-то поменять - в другом месте будут свои "за" и "против"
Код на удалённой машине, я же писал.
Которое тоже решение, просто другое, со своими плюсами и минусами: должна быть машина с белым IP, должен быть стабильный и постоянно активный инет. О вкусах фломастеров можно спорить бесконечно...
Включите Cloud Changes в VS Code (включается автоматом при входе в аккаунт Microsoft) и хоть в браузере работайте на github.dev или в vscode.dev. Можете и в обычном VS Code. И синхронизация Git не нужна.
Я так и пользуюсь, переключаясь с ПК на планшет, когда оказываюсь в кафешке. Очень удобно! Секреты и все изменения исходников автоматически появляются в репозитории, когда оказываешься в той же ветке.
Я ради этой фичи отказался от других редакторов и хранилищ Git, ибо прям чувствую, как наступает будущее, в котором можно в принципе не заморачиваться с синхронизацией - она просто есть и просто работает.
Я для себя решил эту проблему просто:
Храню рабочие файлы в Dropbox, но, когда надо с ними работать, делаю софтлинк файлов в папку за пределами Dropbox. У меня специальная папка для работы. В линуксе софтлинк указывает на новое место а сохраняется в реальный файл. А всякие временные файлы пишется за пределами Dropbox папки.
Работает ли такое в виндовс я незнаю.
Да, такие решения фигурировали в обсуждениях идеи. Но, как мы все понимаем, это костыли, и официальное встроенное решение было бы лучше.
Да, работает
Windows есть три типа файловых ссылок для NTFS томов: жесткие, мягкие (симлинки), точки соединения (Junction point).
Hard Links (жесткие ссылки) – могут указывать только на локальный файл, но не на папку. Такой файл – это ссылка на другой файла на этом же диске без фактического дублирования самого файла. У него отображается такой же размер и свойства, как у целевого файла (но реальное место на диске он не занимает);
Junction Points (Directory Hard Link, точка соединения) – могут указывать только на папку (на этом же или на другом разделе);
Symbolic Links (мягкая ссылка, симлинк) – могут указывать на локальный файл, папку и сетевой каталог на удаленном компьютере (UNC), поддерживаются относительные пути.
В подавляющем большинстве случаев вам будет достаточно функционала symbolic link, как наиболее универсального средства создания ссылки на любой объект.
Как создать символическую ссылку в Windows?
Для создания символических и жестких ссылок в Windows можно использовать встроенную утилиты mklink или PowerShell.
Годы назад перешел с дропа на мегу. Мега умеет фильтровать как минимум мусорные файлы, но я думаю и папки тоже можно. Использовал для фильтрации временных файлов у сохранений в играх, которые умудрялись иногда лимит сожрать (т.к. у меги лимит касается и удалённых файлов, а сейвы перезаписывались создавая для меги события "файл изменён" довольно часто).
MEGA молодцы, они сделали именно то, что нужно: https://help.mega.io/ru/installs-apps/desktop/megaignore
Т.е. они позволяют создать специальный файл .megaignore и указать паттерны для исключения. И эта компания не посчитала, как некоторые в комментариях, что это ненужный функционал. Причём сделали они его даже без громких возгласов аудитории.
Ребята сели и посчитали, сколько денег приносят эти ненужные файлы, и решили не делать фичу. Вы бы хотели создать фичу, чтобы себе зарплату уменьшить?
Как не странно, да. Потому что если вы будете годами игнорировать желания пользователей, то они в итоге перейдут к тем, кто их не игнорирует. Можно конечно попытаться посчитать, скольким клиентам нужна данная фича и каковы будут потери. Сравнить и в случае если уйдет меньше клиентов, чем будет потеря в доходах от новой фичи - не делать. Но это порочная логика, т к по факту вы сами себе конкурентов растите. А с их появлением и укреплением начнется настоящая борьба, которую с большой долей вероятности ваш менеджмент проиграет, т к он уже ориентирован не на улучшение продукта, а только на максимизацию прибыли. Таких примеров пруд-пруди. Чтоб далеко не ходить, можно даже дать что-то вроде предсказания: следующим очень крупным таким примером может стать компания Intel, котрая примерно из той же логики игнорировала улучшение в процессорах x86 последние 10 лет. Они не только не добавляли нового, а ещё и частенько вырезали старое под предлогом не нужности на десктопе. Ну теперь у их конкурента есть все шансы их повалить. Менеджмент уже закапошился, вот только виноватых всегда ищут не тех. Нельзя свою голову пеплом посыпать. =)
Управлять компанией, тем более монопольной или около-монопольной, опираясь только на показатель прибыли - это прямой путь к могиле этой компании. (разумеется если вы не крупный банк, страховое агенство, военная корпорация или крупный гос монополист. Этих всегда спасают и именно поэтому там управление сводится к тому, что бы либо сделать побольше дивиденды, либо отпилить кусочек от бюджета. Мой вариант борьбы с таким - расстрелы за коррупцию и измену родине. Пример - Китай)
Могу предложить заняться разработкой систем анти-ИИ или осваивать, например, животноводство. Чтобы в будущем диверсифицировать свои знания и не остаться без работы (как интел).
Простите, но прислушаюсь к вашему мнению, только когда начнете управлять "около-монопольной" компанией. Пока это набор предположений
А кто вы собственно такой, что бы мне предлагать что-либо ?
И к чему был этот "архи-умный" ответ ? В гос. компании работаете ? Вам написанное глаза колет, потому что делаете так-же ? Или идеологический противник смертной казни ? Ну ок, ведь в Китае не сразу расстреливают Для начала предлагается наворованное вернуть и подельников сдать правосудию. Не переживайте так =)
У нас на работе тоже вводили внутренний сайт идей. Любой сотрудник мог по любой теме предложить улучшение. Компания очень большая , тематик много. Отвечало за этот сайт всего пара человек (больше то и не надо). Когда приходит тикет - они его читают и тупо пересылают в профильную команду, чтоб почитала. Периодически их спрашивать - делать будете, берёте или нет?
И нам иногда прилетали идеи по нашему продукту. И я вам скажу, что большая часть всего что прилетело было либо бредом, либо человек просто не знал, что эта идея будет тупо нецелесообразна (например: давайте всем клиентам дарить крутые подарки после продажи). Короче 90% было мусором, и мы эти идеи просто слали нахер.
Были и толковые идеи, их очень быстро брали, реализовывали, а у самой команды и продакта был неразобранный бэклог идей на 2 года, каждая из которых реально приносила доход.
Я это к чему. В статье много говорится про такой сайт идей, но по факту это просто "приемная Санта Клауса", где работает 1 человек на полставки, который периодически пересылает тикеты продуктовым командам. Поэтому многого ждать от такой штуки не стоит, и процент реализации идей говорят сами за себя.
Я сейчас не говорю, что ваша идея говно. Вовсе нет. Я лишь говорю, что не стоит ждать от такого портала идей слишком многого.
Почему команда не сделала эту фичу за столько лет? Я считаю, проблема в технической сложности. Дропбокс был написан очень давно (уверен, второпях, ведь это был стартап с туманными перспективами), и за столько лет там накопилось столько костылей, что никто уже не понимает как вся эта слишком умная синхронизация работает. Целый час на перекачку 1000 файлов? Они их видимо майнят. И другой ваш пример, когда дропбокс все ещё "трогает" файлы, хотя не должен был - это яркий пример, как там всё всрато. Получается, за идею берется разработчик, понимает что ему слишком страшно трогать самую важную часть ПО, бросает задачу/либо же продакт думает он говно программист и увольняют бедолагу. Берут следующего, который что то там делает, но ломается другая часть ПО, тесты не проходят. И так по кругу все 10 лет :D.
Обычно, гораздо более рабочие каналы - это треды на reddit. Запустить там такой вой - и вуаля! Идею заметит их СЕО, скажет ребятам "чё за дела?" И те быстренько все сделают.
Сложно поверить, что их CEO до сих пор не знает о таком фича реквесте :-) Но я понял, о чём вы говорите касательно недостатка внимания к порталу с пользовательскими инициативами. И для большинства идей такое вполне может быть. Но не для самой запрашиваемой, и не 10 лет.
Про сложности реализации возможно. Хотя это и удивительно (но бывает), что такая крупная компания не может за всё это время реорганизовать код. В принципе это тоже что-то говорит о продукте и управлении им.
Самым первым вариантом решения проблемы Dropbox посчитал хранение информации вне синхронизируемой папки. И хотя очевидна вся абсурдность данного совета, опишем минусы подхода.
Очевидно также, что можно погуглить на тему in-source build vs out-of-source. Многие считают для проектов чуть сложнее "Hello, world" второй подход предпочтительным, хотя MS VS из коробки действительно предлагает по умолчанию первый вариант.
На сегодняшний день у виновника торжества 1300+ голосов
Согласно отчётам о прибыли, количество платных аккаунтов превышает 18 миллионов.
Даже если предположить, что все эти 1300 платят (хотя в реальности скорее наоборот), то эта фича интересует 0,007% покупателей. Вы бы стали решать такую проблему?
Я делал так:
Нужным файлам выставлялся атрибут Архивный
Скрипт по расписанию копировал все архивные файлы и папки в папку Google Drive
Google Drive копировал всё в облако.
Я тоже довольно долго ходил вокруг да около этой задачи.
В итоге нашел https://kopia.io/, выставляю в ней фильтры на то, что не нужно, она по расписанию делает снапшоты данных и отправляет их в удаленный s3. Это не решает кейс: хочу работать в день за двумя разными компами, но я и не очень себе это представляю. Тут помимо данных мне пришлось бы все окружение (программы, настройки, картинку на раб столе наконец) тоже синхронить. А так и данные целы и версии есть (снепы делаются только по дифам практически мгновенно).
Есть вариант лучше - использовать утилиту бэкапа. У себя делаю ею синхронизацию в одну папку для себя и коллег, и инкрементальные бэкапы по событиям в другую папку. У них обычно есть все необходимые фильтры с масками, например, как здесь:
Конкретно эта программа может бэкапить и в дропбокс, и в гугл драйв, и даже на роутер с флешкой/SSD по вебдав или фтп... Поэтому не понимаю страдания автора, 10 лет упорно не замечающего существование альтернатив.
Плюсую, использую для этого FreeFileSync. Она умеет синхронизировать локально, с гугл драйв и SFTP/FTP. Мне хватает, синхронизирую папки проектов в папку OneDrive локально, а дальше уже OneDrive загружает всё в облако. Это, конечно, не дропбокс, но фичи фильтрации файлов у него тоже нет. Да, получается, что локально файлы хранятся два раза, но, может быть, это не так уж и плохо. Если хранятся локально на двух разных дисках -- это тоже повышает отказоустойчивость.
Google one 2tb регион Турция - 50лир/месяц. За год по текущему курсу $17 )
А правильно ли я понимаю, что эту фитчу надо делать именно в клиенте? И если так, то можно ли использовать сторонние клиенты, или Dropbox их создавать запрещает?
Да, нужна поддержка в клиенте. Ну и на сервере по части особой работы с файлом .dbignore (или как его назовут). Про создание сторонних клиентов не подскажу, были такие сообщения в дискуссиях, но я не заметил, чтобы в итоге кто-то счёл это реальным, нужно изучить.
Вот да - например в стороннем клиенте Dropbox для Android, Dropsync, это пункт "Исключать скрытые файлы". Я это для Obsidian использую - он папку .obsidian (с точкой в начале) создаёт - и Dropsync её не выгружает. В Windows приходится PowerShell запускать, что бы добавить NTFS аттрибут. Вообще конечно ппц неочевидно.
А может просто держать ваши рабочие проекты не в папке дропбокса, настроив синхронизацию своими силами любым сторонним клиентом? Хоть локально в папку дропбокса только нужное копировать, хоть прямо с облаком синхронизировать каким-нибудь rclone? А не ждать десять лет у моря погоды.
Ну, это ещё не касаясь того факта, что хранить в облаке информацию не стоит, должен быть оффлайновый бэкап за пределами папки синхронизации.
Вы всё верно пишите, что не стоит ждать у моря погоды. Я уже и не жду, я у себя сделал примитивное решение в виде PowerShell-скрипта, который нужно запускать. Но мне кажется неверным видеть что-то неудобное и просто молча делать костыли с мыслями "Ну ладно". Всё же встроенное решение есть самый правильный путь, Мечты...
А оффлайновый бэкап всегда есть локально на компьютере. Хотя Dropbox позволяет включать режим online-only для сохранения места на диске (и некоторые им пользуются), я всё храню автономно на своём компьютере.
Сколько лет эта проблема существует, примерно столько же я с ней борюсь. В моем случае это исключение папки node_nodules. Поначалу делал символические ссылки на Винде, было костыльно и не удобно.
Потом нашел специальную программу, goodsync вроде, использовал ее. Тоже со своими проблемами. Она очень долго делала анализ того, что надо синхронизировать, поэтому настраивал ее на использование раз в час. И в облаке не всегда был свежий проект. Если кому-то нужно было отдать ссылку на актуальный билд, то "запускай синхронизацию руками и жди минут 15-30"
Потом дробпокс таки выкатил тему с исключением папки с помощью командной строки, тоже тот ещё гемор, конечно, но сейчас делаю так.
В какой-то момент эта опция появилась в контекстном меню, что было проще, чем вводить длинную команду, но потом, конкретно у меня, по крайней мере, вновь пропала.
Так что сейчас я вновь исключаю node_modules помощью командной строки. Но тут надо целый алгоритм выстроить, чтобы все работало:
Отключить синхронизацию дропбокс
Создать проект и установить зависимости, чтобы там появилась папка node_modules
Прописать исключение из синхронизации для этой папки
Включить синхронизацию
По итогу тоже довольно неудобно, конечно. Почему не могут сделать глобальный фильтр в настройках, не понятно
Это вы еще мобильное приложение Bandcamp не видели. Пользователи лет 15 просят сложнейшую фичу - возможность удалить трек из своей коллекции музыки.
А какие другие "облака" позволяют указывать что вот те папки (а точнее тип папок) надо игнорить?
Всегда воспринимал облака именно как "хранилище", файлы, музыки, дистрибутивы
а при активной работе с этими данными, когда создаются какие-то временные файлы, я вообще отключал (в данном случае мейл-облако), чтобы оно не дергало диск, считывая постоянно возникающие новые временные файлы. Закончил работу - включил синхронизацию обратно
С Onedrive кстати тоже проблема, если на рабочем столе куча здоровенных файлов, то при их редактировании, изменении, добавлении. Или при медленном интернете.. Возникают затупы. А то и дубли появляются
Ну, например, в MEGA сделали именно то, что требуется: https://help.mega.io/ru/installs-apps/desktop/megaignore
В Koofr тоже: https://koofr.eu/blog/posts/advanced-ways-to-exclude-files-from-sync-part-2
Есть зачаточное решение у pCloud: https://www.pcloud.com/help/drive-help-center/how-do-i-exclude-files-or-folders-from-my-backup-sync-or-ongoing-transfers-in-uploads
это ж аналоги гитигнор? (у меги, который)
а чего им гит не устраивает?
или любой другой локальный сервис синхронизации
Ну типа работаем в папке рабочей, раз в сутки запускается скриптик, который копирует из рабочей папки в папку облака
собственно на многих работах, так и делают, содержимое раб стола и мои документы либо сразу находится на сервере, либо туда копируется регулярно. причем даже некоторые кол-во дней хранятся версии
(ну то есть принцип как на сервере, никто ж не делает синхронизации на боевом сервере, раз в сутки делают бекап, ночью)
а так, ну вот это хранилище не поддерживает гит игнор или мега-игнор, ну так можно использовать другие варианты
Кстати с точки зрения разработки, а пароли то ? где пароли? не утекают они тоже в облако? А если нет, если пароли лежат в файлике отдельно, значит если полетит ссд-шка, то все, данные то у нас в облаке, а пароли пролюбили
Облако всё делает за вас - хранит, синхронизирует, ведёт историю, читает ваши файлы и сливает их данные третьим лицам...
Облако (по идее) хранит файлы более профессионально и надёжно: не на одном серваке (как в Storage Box у Hetzner), а несколько копий в географически распределённых ЦОДах.
"Сливание данных третьим лицам" предотвращается шифрованием папки (простейшим encfs).
Как повезёт. Зачастую эти копии в одном датацентре, пусть и на разных серверах. Но, в любом случае, это чужой дядя. И он в любой момент может ваши файлы грохнуть или доступ к ним прикрыть. Без злого умысла, просто так получилось.
Мои основные принципы работы с облаками:
1) Считай, что всё, загруженное в облако, ты сразу открываешь на доступ неопределённой группе лиц. Так что приватное не туда не класть, а если всё же кладёшь - шифруй.
2) Данные в облаке и папке их клиента не хранить, всегда должна быть актуальная копия где-то в сторонке.
После того как убрали веб сервер на папку, пользоваться им стало совсем грустно.
Странно, но никто не упомянул яндекс.диск. Переехал с дропбокса в момент, когда они отменили бесплатный тариф, сначала на бесплатный диск яндекса, а сейчас уже покупаю. И чем дальше, тем больше мне он нравится. Да, сначала стабильность хромала (именно api), но сейчас проблем давно не испытываю. А с вводом возможности покупать место сразу на семью, так вообще ничего другого и не нужно.
Есть мнение, что пользоваться сервисами Яндекса - зашквар и моветон для любого продвинутого айтишника, и что от яндекса ничего хорошего быть не может. В действительности это, конечно же, не так, я с удовольствием пользуюсь всей экосистемой и доволен как слон. Большинство сервисов Яндекса удобнее и функциональнее аналогов. К Диску главная претензия - иногда плохо работает WebDAV плюс нужно создавать отдельный пароль. Однако УМВР и для меня единственный недостаток - невозможность загружать на бесплатном тарифе (даже с подпиской Плюс - ну как так!) файлы свыше 1 ГБ.
К Яндексу, и вообще к российским сервисам, ещё есть вопросики вне технической части - но вообще-то их стоит адресовать по другому адресу.
...невозможность загружать на бесплатном тарифе (даже с подпиской Плюс - ну как так!) файлы свыше 1 ГБ.
Счастливый Вы человек! Если совсем припрет, Вам достаточно добавить совсем немного рублей, и вуаля - здравствуйте, файлы по 50Гб! А мы вот уже уперлись в планку 50Гб... .И, кажется, она не будет преодолена никогда :-((
А как все хорошо начиналось...
Давным-давно, когда всем еще хватало 640Кб, у нас уже были временные ряды размером под мегабайт. Или поменьше, но сразу десяток. Монстры типа Мезозавра с ними работать отказывались, да и вообще выглядели ущербным убожеством по сравнению с нашими представлениями о прекрасном. В общем, мы тогда запилили собственную узконишевую СУБД временных рядов с весьма нестандартной архитектурой и минимальными пожеланиями к "механической части". Которая уже почти сорок лет постепенно докручивается под наши задачи, так что сейчас она вполне себе может покуривать гигабайтные временные ряды на самом убогом железе родом из 2000-первых. Лишь бы диск был большой и быстрый (ну и кэш желательно поумнее, если, конечно, на компе есть свободная ОП). Так бы мы с ней и жили в благоразумии и достатке... только вот недавно один мой коллега перепутал по глупости буквы в компьютере, и закинул нашу общую базу на Яндекс-диск. После чего неожиданно выяснилось, что наша древняя СУБД прекрасно работает с этим диском. Т.е. нам теперь больше не нужно пересылать свои базы друг другу тайными тропами: достаточно залить данные в облако, и вуаля: теперь с БД могут работать сразу несколько юзеров из самых разных локаций
Точнее, если быть честным, то совсем одновременно не могут, но это уже отдельная история. Впрочем, она прикольная, так что я, пожалуй, и ее расскажу
Вообще-то наша СУБД всю жизнь была персональной, то бишь однопользовательской. Никаких тебе механизмов авторизаций, прав доступа и т.д. Только свой личный комп, файлы с данными и довольно простая программа, которая обеспечивает интерфейс между файлами данных и интегрированной с ней средой анализа/обработки рядов. Только вот по мере появления новых юзеров из научной среды (многим из которых было под 70), неожиданно выяснилось, что такую примитивную беззащитную базу довольно легко поломать. А именно, если юзер забыл, что база уже открыта в одном окне, и запустил второй экземпляр программы, то они начинали конфликтовать. В лучшем случае просто ругались на отсутствие доступа, а в худшем (при попытке одновременной записи в базу) и вовсе могли там что-то испортить. Короче, чтобы не искушать судьбу, я на коленке сделал простенький механизм блокировки, чтобы второй экземпляр программы не мог открыть базу, пока над ней издевается альтернативный клиент. Его и механизмом-то назвать сложно: де-факто это просто флаг в специальном служебном файле. Какая проблема (читай защита от дурака), такое к ней и решение ;-)
А хохма произошла в тот миг, когда мы закинули свою базу на Яндекс-диск и начали с ней работать одновременно из Пущино, Москвы и с Камчатки. Я не могу логически объяснить произошедшее недоразумение, но внезапно выяснилось, что этот простенький механизм родом из 1990-х вполне себе справляется с управлением доступом к облачной базе. Юзеров у нас мало, запись в базу происходит лишь по большим праздникам, поэтому синенькое окошко с надписью "подождите минутку, пока база освободится" не напрягает вообще. Вот тут-то, подумал я, карта нам и попрет... Да вот не тут-то было.
А проблема в том, что у нас многие ряды 100-герцовые. А программа все же не настоящая СУБД, и архивировать данные "на лету" не умеет. Так что на каждое значение временного ряда ей два байта вынь да положь, а то и четыре... А 100Гц - это 3Е+9 значений в год, которые удобнее всего хранить в одном пополняемом файле (у нас каждый сигнал - это отдельный файл). Короче, лимита 50Гб хватает максимум на несколько лет измерений. Можно, конечно, делить длинные ряды данных на части, а перед анализом склеивать (рабочее пространство программа себе все равно организует на локальном диске для скорости), но это уже совсем не тот коленкор :-(
В общем, проблему 50 гигабайт мы так и не можем пока решить. Буду благодарен, если кто-то подкинет идею, как это ограничение обойти. Проблема в том, что нам при работе эти файлы нужны в натуральном виде, неупакованные. Чтобы программа могла в любой момент сделать open и немедленно прочитать/записать из файла значение по произвольному заранее известному адресу. Причем читаются только данные, и обычно последовательными блоками; timestamp при этом нигде не хранится, а вычисляется за пренебрежимо малое время. Т.е. побочные "накладные расходы" равны нулю. Скорость ограничивается исключительно диском. Поэтому данные хочется получать так быстро, как только система физически может их отдавать.
Ну и еще очень хочется, чтобы в случае изменений в файле процесс синхронизации с облаком начинался немедленно, а не после того, как его кто-то заархивирует. С небольшими файлами (до 50Гб) все именно так и работает. А как быть с большими?
Разбить файлы на части для кастомной базы вроде не должно быть супер сложной задачей.
С одной стороны - да, не сложно. Собственно, на уровне юзера нам никто не мешает это делать прямо сейчас. Но это морально тяжело, да и вообще как-то "без уважения" (с). Ибо при каждой загрузке данных в рабочее пространство юзеру придется надевать на голову шапочку с бубенцами и совершать некое танцевальное па.
Можно сделать и на уровне СУБД, конечно. Но во-первых, это здорово запутает логику алгоритмов. Сейчас-то у нас один ряд = один бесконечный файл. Проще не бывает. Как говорится, работает-не трогай. Да и зарплата у нас идет за выкопанные кубометры данных, а вовсе не за прикрученные к самодельной лопате фичи. Ну и вообще, хочется тратить время на более творческие задачи, а не на борьбу с техническими ограничениями...
А во-вторых, в существующей архитектуре БД возможность такого дробления ряда данных на несколько файлов не предусмотрена. Придется менять не только коды программ, но и форматы системных (служебных) файлов БД. Это неминуемо нарушит обратную совместимость. Чего нам делать крайне не хочется, т.к. мы постоянно передаем свои базы между коллегами, а в этом случае любая база, сделанная в новой версии программы, перестанет читаться в прошлых версиях. Для нас это
практически табу
что неудивительно, если вспомнить, что все написано на фортране ;-)
Который, между прочим, до сих пор обязан компилировать код родом из 1960-хх
А если серьезнее, то в последний раз мы нарушали обратную совместимость при переносе всей системы из DOS в Windows. Там просто деваться некуда было. Разумеется, при этом мы зарезервировали тьму полей для будущих расширений (примерно половина из которых уже использована). Но вот разбиение сигнала на несколько файлов в эту систему не вписывается от слова никак.
Правильно понимаю, что у вас write-once БД без обновления данных?
Писать с автоматическим разбиением и читать с автоматической склейкой, используя файлы .dat, .dat_1, ... сильно проще, чем что-то ещё городить. Нет никаких проблем, как кажется, допилить модуль работы с дисковыми файлами, чтобы он сам вычислял постфикс для файла при записи и чтении.
...у вас write-once БД без обновления данных?
На самом деле нет. При длительных полевых (внелабораторных) наблюдениях первичные данные всегда ужасно замусорены. Львиная доля времени при работе с такими данными уходит на их
первичную обработку
Под первичной обработкой мы понимаем устранение из сигналов более или менее очевидного брака, который иногда вычищается, а иногда корректируется. Не поверите, но это целая отдельная отрасль исследований уже. Без такой обработки геофизический мониторинг становится больше похожим на астрологию, чем на науку. Так как незамеченные вовремя глюки в данных запросто могут привести не только к потере реальных эффектов из-за их зашумления, но и к появлению фантомных артефактов, которые кажутся высокозначимыми, а на самом деле это просто пустышка. А заметить эти глюки совершенно не просто. Раньше этим занимался эксперт с прищуренным взглядом,
визуально просматривая все экспериментальные временные ряды
Ну или не занимался, а сразу же приступал к статистической обработке сигналов... в результате чего в свое время была совершена неисчислимая куча чудных открытий, которые даже публиковались в хороших журналах, а сейчас лежат толстым слоем на мусорных свалках.
А сейчас визуально уже не проверишь - объемы данных не те. А самое интересное, что
и автоматический контроль не справляется
Так как автоматические алгоритмы можно обучить лишь на ранее замеченных глюках.. но при исследовательском мониторинге в сигналах постоянно появляются глюки нового типа, которых ранее никогда не встречалось. Причем почти для каждого вида наблюдений эти глюки свои. Типизация багов в данных более-менее устаканивается обычно лишь через 5-10 лет наблюдений. Только вот за это время либо наблюдения кончатся (начнутся другие), либо аппаратура изменится, либо еще что-то случится, что однородность данных (и, соответственно, глюков) нарушит. И начинай все сначала.
В общем, без первичной обработки рядов - никак, а вот как ее правильно сделать - никто не знает (либо знает, но держит в секрете ;-) Так что это уже не совсем наука, а отчасти философия. Если вдруг интересно подробности, гляньте вот эту статью: Проблема качества данных при режимном геофизическом мониторинге: кто виноват и что делать? и ссылки оттуда.
И, естественно, при этом запись в БД идет постоянно, чуть ли не после каждого шага. По факту, там хранится не только первичный сигнал (который действительно write-once), но и его различные версии с разными уровнями очистки. Которые на определенном этапе работы редактируются постоянно.
Но даже после того, как первичная обработка сделана, начинается содержательный анализ, и он тоже, как правило, многоэтапный. Рядов у нас не так много, каждый чем-нибудь уникален, поэтому мы к этим данным возвращаемся много раз, рассматривая их под разными углами и уточняя всякие алгоритмы. При этом хранить в базе все промежуточные результаты нельзя по объему, но некоторые сохранить хочется (чтобы после не пересчитывать). И вот эти промежуточные результаты редактируются сплошь и рядом.
Писать с автоматическим разбиением и читать с автоматической склейкой, используя файлы .dat, .dat_1, ... сильно проще, чем что-то ещё городить.
Все это можно сделать, конечно. Причем вне зависимости от "write-once". Тем более, что слой работы с файлами данных у нас достаточно изолирован от других слоев. Но при этом нарушится обратная совместимость, а этого очень не хочется. Ну и просто ресурсы времени ограничены. Ревизия базы - это все-таки техническая задача, а заниматься хочется творческими в первую очередь...
Жениться программиста вам надо, барин, для которого аот эта переделка базы - самое что ни на есть творчество. Эх, где мои 17 25 лет, когда я именно таким и занимался...
Жениться программиста вам надо, барин,
Так у нас же тут монастырь наука... Простому программисту платят как инженеру: оклад ЕТС и маленькую надбавку. Ему у нас никакого интереса работать. Еще и стек такой, что кроме Большого Каретного инженерных расчетов ни в каком IT-закоулке больше не пригодится...
Точнее, в 25 лет интерес может состоять в том, чтобы выйти в научники, после чего можно будет свое любопытство за госсчет проверять. Тогда уже будет шанс и рыбки поесть, и чешую продать и творчеством заниматься, и зарабатывать что-то (не так, как в IT, но ощутимо выше средней по региону). Только вот когда человек сам себе ставит задачи и сам статьи пишет, то у него уже обычно собственных идей куча, и чужие технические вопросы неинтересно решать :-(
для которого вот эта переделка базы - самое что ни на есть творчество.
А вот тут Вы меня (страшно далекого от народа), без шуток, пугаете. Если для настоящего программиста такая вот переделка чужой базы - творчество, то что же тогда для него рутина?
Рутина - это байты перегонять да формы шлёпать. А когда берёшь неживое, и делаешь так, чтобы оно летало, танцевало и говорило "папа", мммм
Возиться с легаси - это обыденность для программистов. Но одно дело - лепить бесконечные костыли, а другое - переделать так, чтобы и самому понравилось, и другим не стыдно показать, и работу не сломать.
Я именно таким занимался один год в начале, в аптечной сети. До сих пор приятно вспомнить.
Но платили смешно, конечно. Вот примерно как у вас. Так что я БД починил, да дальше пошёл. Увы, многие на моём месте сбежали бы раньше.
А что в науке и жнец, и жрец, и на дуде игрец - да, много таких знакомых, которые сами себе программы пишут. Как программисту мне на такое смотреть больно, но я понимаю принцип "работает, и ладно", у самого такое отношение к той же машине. Ездит, и ладно.
Так выкиньте яндекс.диск из уравнения и перейдите на syncthing. У него и минусов - отсутствие своего хранилища, но для тех, у кого своя машина онлайн это не проблема. Ну или скрипт-обёртку вокруг rsync, но это уже требует скила.
Так выкиньте яндекс.диск из уравнения и перейдите на syncthing.
Спасибо за наводку! Почитал вики, выглядит интересно! Хотя одна проблема сразу видна: у нас нет постоянно работающих машин. А для синхронизации надо, чтобы они были в сети одновременно....
И в продолжение темы: я правильно понял, что Вы им пользуетесь?
Можете ли тогда уточнить пару нюансов?
1) Как syncthing определяет, где самая последняя версия файла? По дате? Я имею в виду случай, когда машин много, и они подключаются к сети не одновременно. Скажем, машин четыре, но онлайн они обычно бывают попарно в разных комбинациях. Например, пускай самая свежая версия файла у нас на компе N1 (ее добавили, когда он был офлайн). Потом в сети появляются N1+N2, файл синхронизировался, все Ок. Затем N1 и N2 отключились, а в онлайне появились N3+N4. Запоминает ли где-то прога, что на машинах N1 и N2 есть гораздо более новая версия файла, и поэтому синхронизировать N3 с N4 нет никакого смысла? Т.к. надо ждать заонлайнивания N1/N2 и сразу качать оттуда?
И вообще, сообщит ли syncthing юзерам N3+N4 о возникновении такой ситуации?
.
2) Что будет, если две машины N1+N2 обе были в офлайне, и юзеры отредактировали один и тот же файл каждый у себя? Потом оба компа заонлайнились. Прога заметит, что изменены ОБА файла, или тупо синхронизирует по дате? А если заметит, то что будет дальше?
.
3) И третий вопрос. Можно ли как-то спросить у syncthing, синхронизирован ли У МЕНЯ некий файл X, или же его синхронизация идет прямо сейчас в данный момент? Например, можно ли послать соответствующему процессу сообщение с просьбой вернуть статус файла? Или легально прочитать этот статус в служебном файле syncthing?
На Я-диске такого сервиса нет (только неполноценный синенький индикатор в панели задач, показывающий, что синхронизация чего-то там продолжается). Нам это не очень удобно, т.к. вынуждает использовать всякие костыли. Вместо того, чтобы напрямую задать этот вопрос Я-API, мы сейчас пишем в облако небольшой дополнительный служебный файл со статусом базы, и пытаемся по нему определить, выждав паузу, завершилась синхронизация, или нет. В надежде, что этот микрофайл синхронизируется достаточно быстро (что никто нам не гарантирует, на самом деле)
.
4) Ну и четвертый вопрос. По идее глупый (в наше время странно предполагать иное, но мало ли). Если одна из машин отваливается во время синхронизации, то после переподключения синхронизация продолжится того же самого места, правильно? Даже если целевой файл изменился?
Более точно: у нас чаще всего начало файла не изменяется, но к нему могут добавляться новые куски в конце. Из вики я понял, что syncthing такие штуки умеет отслеживать, и будет синхронизировать только эти изменившиеся куски, так? Так вот, если во время синхронизации такого куска связь прервется, а новое включение произойдет уже после того, как к файлу добавится еще что-то, то такая ситуация обработается корректно?
.
Заранее спасибо за ответы! Если Вы в курсе этих деталей, конечно...
Постараюсь ответить на ваши вопросы.
Синктинг сравнивает файлы по mtime и хешу и помнит состояние на момент предыдущей синхронизации. Если он видит, что файл поменялся с прошлой синхронизации, то попытается его распространить. Касательно вашего примера, у syncthing нет единого центра, где хранилась бы правильная метаинформация. Если в сети окажутся только N3 и N4, то они попытаются синхронизироваться как если бы всего остального мира не существовало.
syncthing обнаружит ситуацию конфликта. Разрешить её самостоятельно он не может, а потому скачает все варианты файлов и сохранит под очевидными именами и покажет уведомление в интерфейсе. Юзеру нужно будет разобраться самому и удалить лишнее. У вас тут может возникнуть вопрос, а не станет ли синктинг качать дважды по 50гб. По идее не должен, по крайней мере в момент обнаружения конфликта. Но тут надо проверять и курить доки. Возможно, есть настройка "при конфликтах - просто стоп!"
Да, есть REST API где можно всякое разное узнавать, например через /rest/db/need посмотреть очередь. В штатном веб-гуи виден лог.
Я не знаю. Мне самому синктинг продали как "включил и работает" и оно действительно для меня работает. Другие люди точно синхронизируют синктингом образы дисков. Также для менеджера паролей keepassxs рекомендуемая конфигурация "синхронизирйте синктингом даже во время записи и чтения в базу". Так что ни большой размер, ни работа с файлом без прерываний и блокировок не проблема. Но вот пограничные случаи как у вас - надо проверять.
С Яндекс диском очень медленная синхронизация через rclone. Насколько помню, Яндекс принудительно замедляет трафик от rclone.
А вот облако мэйл ру, как ни странно, работает с rclone очень быстро и без сбоев. Так что предпочел его.
Было бы интеересно узнать, как это реализовано у других файловых хранилищ, приведенных в статье
Google One
Microsoft OneDrive
Sync
pCloud
MEGA
Выглядит как наезд конкретно на дропбокс, при этом непонятно, на сколько это вообще сложно реализуемая фича (иначе была бы у всех конкурентов). Я склонен согласиться с другими комментаторами, что если бы так было просто реализовать, то уже сделали бы. А отчитываться почему не могут/не хотят они не обязаны
P.s. не отрицаю наличие проблемы, самому не нравятся предлагаемые настроки синхронизации, приходится костылить
Выше написал комментарий, повторю:
Ну, например, в MEGA сделали именно то, что требуется: https://help.mega.io/ru/installs-apps/desktop/megaignore
В Koofr тоже: https://koofr.eu/blog/posts/advanced-ways-to-exclude-files-from-sync-part-2
Есть зачаточное решение у pCloud: https://www.pcloud.com/help/drive-help-center/how-do-i-exclude-files-or-folders-from-my-backup-sync-or-ongoing-transfers-in-uploads
Кстати, забавно, что именно самые крупные сервисы облачного хранения не реализуют данную фичу: Dropbox, Google, Microsoft. Хотя реализация данной штуки, хоть, возможно, и не значительно, но была бы преимуществом перед конкурентами.
Наезд на Dropbox связан с наличием портала, куда пользователи могут публиковать идеи, с наличием самой запрашиваемой фичи и с откровенным безразличием к такой идее со стороны компании в течение 10 лет.
Примерно такая же ситуация была с Confluence. Вертикальное выравнивание в ячейках таблицы делали больше 10 лет. Хотя, казалось бы... Для self-hosted реализовали год назад (причем для более дорогого Datacenter edition), а для облачной версии ждем до сих пор...
Для себя решил проблему с помощью Syncthing. Планирую таким же способом уйти с Google Photo – поставить Immich и синкать все фото и видео с телефона.
Причём, у них давно уже есть игноры с шаблонами. Достаточно туда бахнуть node_modules и подобное и забыть. Вылизывали они это всё долго, но можно понять — система децентрализованная, и граф устройств и папок может быть аболютно произвольно-безумный. Вдобавок, между платформами бывают разные соглашения об именовании файлов и директорий: некоторые символы запрещены на некоторых ОС (типа windows), где-то названия регистрозависимые, где-то нет, где-то длина имени файла или пути лимитирована одним числом символов, а где-то другим, и байтов, и всё это должно в любых комбинациях работать, не удаляя внезапно файлы. Но вроде уже несколько лет никаких проблем не было.
Такое впечатление, что люди создают проблемы и обижаются, что их не решают. Проекты и исходники надо хранить на гитхабе.
Лично я использую дропбокс для синхронизации с читалкой и не пихаю в бокс все подряд.
Мне нравится подход дропбокса. Мы разработали продукт и он умеет ровно вот это (список). Не более. Впихивать туда все хотелки и идеи всех пользователей мы не намерены. Можете покупать, если он вам подходит. Если не подходит - походите по рынку.
Обижаться на продавцов автомобилей, что их продукт не умеет копать землю (а чо такова? Колеса есть, осталось прикрутить ковш! Очень полезная фича, многим нужна.) глупо и бесперспективно.
Проекты и исходники надо хранить на гитхабе.
Домашний каталог с исключением всех ~/.cache/
Общий каталог работ, в котором далеко не всё можно и имеет смысл коммитить, и при этом у каждого подкаталога может быть своя специфика, что не синхронизировать.
Это с ходу. Могут быть и более хитрые случаи.
Обзывать всё, что не подходит под тупой шаблон, "исходниками" и посылать на гитхаб - некорректно.
В одном месте, закончив кодить
git bundle ~/dropbox/mirai.bundleПотом в другом
git fetch ~/dropbox/mirai.bundleА прямо в Dropbox сырцы хранить - ну такое...
А кстати, почему люди для синхронизации файлов между устройствами пользуются облачным хранилищем, а не средствами для собственно синхронизации? Я понимаю сценарий, когда основной компьютер один. Но когда у пользователя есть домашний комп, рабочий комп и ноутбук - зачем передавать четвертую копию файлов товарищам майорам, искусственным интеллектам, рекламодателям, хакерам и вообще всем желающим?
А какие альтернативы?
Либо ручками таскать на флешках, что не очень удобно
Либо синхронизация в режиме "устройство 1 -> устройство 2", когда оба должны быть онлайн, что не очень удобно
Либо какой-то промежуточный сервер-хранилище обязательно появится. Самому его поднимать или брать готовый - вопрос цены и трудозатрат.
Потому что облако постоянно включено и доступно отовсюду. Компьютеры и прочие ноутбуки зачастую сидят за файрволами и прямой доступ между ними не так просто бывает организовать.
Потому что облако постоянно включено и доступно отовсюду.
Ну да, забыл, у некоторых людей есть привычка постоянно включать-выключать домашний компьютер. Тогда да, вечнодоступное облако.
Компьютеры и прочие ноутбуки зачастую сидят за файрволами и прямой доступ между ними не так просто бывает организовать.
Syncthing вроде не жалуется на файерволлы, отсутствие белого IP и прочие неудобства. По крайней мере мне не пришлось ничего делать, только установил и сказал: вот здесь синхруй, вот здесь не синхруй.
Либо какой-то промежуточный сервер-хранилище обязательно появится.
Скоро у всех и так VPS будут, потому что без них только с Яндекс-диском связь и останется. Да еще с Госуслугами и Мейл.ру, чтоб электронные повестки приходили.
у некоторых людей есть привычка постоянно включать-выключать домашний компьютер.
Не у некоторых, а у большинства. И рабочий тоже. А уж ноутбук постоянно включенным и в онлайне точно никто с собой не носит.
По крайней мере мне не пришлось ничего делать, только установил и сказал: вот здесь синхруй, вот здесь не синхруй.
А мне пришлось ещё порты пробросить, чтобы скорость нормальная была точка-точка, а не через релеи всё шло на 10 мегабитах.
Скоро у всех и так VPS будут
Во-первых, не у всех, во-вторых, впс с большим диском стоят сравнимо с облаками. Я вон яндекса купил на 2ТБ только потому, что это по акции выходило дешевле, чем мой тариф на 100 гигов на год продлять. Обошлось что-то типа 700 рублей в год.
После того как они вместо старого удобного клиента выкатили тормозное чудище, ушел на мегу и не жалею.
Onedrive 6 аккаунтов по 1тб за 89$
Достаточно узкая проблема. Конечно, .dropboxignore — это было бы лучше, но решение-то есть. У меня некоторые проекты тоже в Дропбоксе, мне удобно. Синхронизацию папок типа node_modules отключаю обычным способом через командную строку: https://help.dropbox.com/sync/ignored-files. Но мне, правда, это приходится делать условно раз в полгода.
Тем не менее, первый комментарий датируется 16 декабря 2014 года.
Опубликована тема была действительно 18-го (26 minutes ago), но ни одна ссылка с той страницы не была проархивирована. А в более поздней версии от 2022-12-05 (раньше нету) я заметил, что наверно разработчик Christopher N.1 (2014-12-18 11:38AM) закинул комментарий от Antoni A. (2014-12-15) в свежесозданную тему (2014-12-18 11:16AM). Откуда - не ясно. That's all, folks!
Идея хранить исходники в git не такая уж плохая.
Как в системе контроля версий? Безусловно.
А как хранить и синхронизировать их в облако - это другой вопрос. Если имеется в виду "на GitHub" - приватные репозитории стоят денег, а выкладывать свой код на всеобщее обозрение не хочется.
Выше озвучивали вариант с git bundle. Или можно хранить в Dropbox только папку .git, а непосредственно рабочую папку создать с помощью git worktree, тогда все конфиги репозитория будут тоже синхронизироваться.
Эх сейчас бы сорцы в обжект сторадже хранить.
Забавно, как много здесь ультимативных комментариев типа "сорцы надо хранить на гитхабе. Точка." Ну может, сорцы и надо. Хотя мне очень не хотелось делать всякие официальные репозитории для говнокодерских скриптов с решениями разных задачек с проекта эйлера и прочих литкодов. По ряду причин. А хранить их хотелось.
Но почти полностью игнорируется тред про фотографии. А я не уверен, что грузить кучи промежуточных изображений (я не фотограф, возможно, не понял до конца) в гитхаб - крутая идея. Или, допустим, некоторые ml-модели обученные.
Да, конечно, советы типа "ну вынесите куда-то далеко нужные папки, до которых дропбокс не дотянется" имеют право на жизнь. Или "наделайте линков". Но некоторым очень не хочется менять наработанный за годы пайплайн рабочего процесса. Куда проще было бы использовать фичу, которая кажется очевидной для сервиса, который "просто синхронизирует файлы с облаком" — синхронизировать не все файлы. С возможностью уточнения понятия "не все".
Сам был удивлён, сколько людей мыслят в духе "Мне это не нужно, есть обходные варианты, значит фича ненужная!". И одно дело просто предложить другие способы на подумать, но нет, именно ультимативно заявляется, что идея неверная.
При этом сколько уже было сказано, что функционал нужен не только программистам (это и в статье есть). А даже если и программистам, то не все проекты хочется публиковать (пусть и в приватные репы) на GitHub. Если я подключу второй компьютер и захочу поиметь все эти мелкие квазипроекты на нём, мне на всё репы заводить и git clone вызывать? Действительно, удобно.
Эх, вот хотел перестать отвечать же, но тут что ни реплика то пушка.
Есть решение, которое при известных рамках подходит для хранения исходников программистам всех возрастов, религий, уровня вздорности и тяги к изобретению нескучных обоев.
Оно называется git. Это не обходной вариант хранения исходников, не передергивайте, это вариант с которого все началось и продолжается до сих пор. В сущности, это единственный вариант, если вам работать, а не шашечки. Причины, по которым вам «не хочется публиковать в приватную репу» НУЖНЫЕ вам на другом пути проекты совершенно однозначно, на мой взгляд, покоятся где то в вашей голове и вне нее не существуют.
Они могут повторяться в других головах при повторении ряда специфичных вводных, но более легитимными от этого не станут.
На этом все. Никто, кроме вас, костылей тут не изобретает.
Вы, блджад, вдумайтесь: вы буквально требуете, чтобы файлопомойка скопировала с VCS функционал, но отказываетесь использовать origin этого функционала, где он уже давно есть.
А, ну и фраза про СЕО дропбокса, на счет которого вы полагаете, что он в курсе вашего несчастного фиче риквеста - это топ. Кто еще в курсе, Маску еще не рассказывали?
Короче, вы придумали херню ради херни, которая ничего не дает по сравнению с существующим решением, ПРИБЛИЖАЕТ другую платформу к целевому решению функционально, и развели на этой почве обсуждение ничего с никакой целью, только чтобы увидеть какие все зашоренные, вам, изобретателю новодела, дорогу не дают.
Вы случайно вечный двигатель не собирали в этом году на ютубе? А то я вас там видел, кажется.
Если я подключу второй компьютер и захочу поиметь все эти мелкие квазипроекты на нём, мне на всё репы заводить и git clone вызывать
Нет конечно, создаете один репозиторий (у меня он называется different-shit), внутри него создаете все эти мелкие проекты и вообще любые файлы в подкаталогах, ну и собственно всё.
В момент, когда мелкий проект вырастает, переносите его в отдельный репозиторий, опционально - сохранив историю коммитов.
в моем случае не промежуточных - а входящих. все 30-130 гигов отснятых исходников, из которых 95% будут удалены через двое суток.
Спасибо. Я сам долго мучился с вопросом фильтров в дропбоксе. Вчера, благодаря статье, пересел на MEGA, и с утра испытываю невообразимое счастье. Файлов синхронизации уменьшилось на 200к благодаря фильтру node_modules и нескольких временных папок. К тому же при включенном дропбоксе проводник windows жутко тормозил. Сейчас отклик проводника девственно быстрый. Плюс цена почти втрое меньше и принимают крипту.
Странно что при таких доходах, дропбокс не могут переписать свой клиент хоть с нуля.
Сказать по правде, Дропбокс - это один из тех сервисов, в котором мне бы хотелось, чтобы ничего вообще не меняли и не улучшали.
Возможно манагеры Дропбокса считают, что подобных мне пользователей большинство.
Зачем использовать облако для синхронизации исходных кодов?
Возможно конечно это какая-то особенность frontend разработки, судя по количеству упоминаний node_modules.
В своё время клиент Dropbox умел не синхронизировать большой контейнер VeraCrypt/TrueCrypt при незначительном изменении (например сохранении небольшого файла), оперируя отдельными блоками файла и синхронизируя только их. OneDrive и ЯндексДиск перезаливали весь контейнер целиком. Это было большое конкурентное преимущество. Интересно, как сейчас с этим обстоят дела у современных облачных хранилищ и не потерял ли клиент Dropbox этот механизм?
Dropbox: как игнорировать пользователей 10 лет