Ads
Comments 26
я призадумался зачем DropBox вводить такие ограничения и мне кажется дело в дедупликации которую они активно эксплуатируют и которая позволяет им экономить на хранении — зашифрованные личным ключом файлы всегда уникальны и дедупликации не поддаются, так что возможно это чистая коммерция.

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

Скорее всего, просто криворукие. Как криворукие мозилловцы прокатили тех, у кого нет пшшшаудио, отрезав поддержку alsa…
В случае же дропбокса есть минимум два способа остаться на нём малыми силами. Первый — запихать раздел дропбокса в файл — контейнер с екст4 и подмонтировать его. Второй способ — есть патч дропбокса, легко гуглится.

Когда я последний раз (несколько месяцев назад) проверял, то в www-client/firefox — да, звук есть, а вот в www-client/firefox-bin — увы, без apulse его нет. К сожалению, там был довольно слабый комп, 2GB RAM, и собрать firefox из исходников там уже нереально.

Не совсем уловил конструкцию с find — он же вернёт существующие в этот момент файлы/каталоги, что будет если Вы создадите новый подкаталог с файлами, их entr отследит? Если да, т.е. он умеет рекурсивно добавлять новые цели в мониторинг на лету, то тогда почему нет возможности передать ему один корневой каталог параметром и чтобы он сам добавил на мониторинг всё его содержимое? Если нет, т.е. нужно вручную не забыть перезапустить сервис после создания новых файлов и/или подкаталогов, то это решение так себе получилось.

Судя по сайту eradman.com/entrproject, entr не умеет рекурсивно.
Поэтому ему нужно поименно добавлять все файлы/каталоги для мониторинга. Если там такой уже есть, то ничего не произойдет. Таким образом find просто обновляет список файлов и каталогов в entr.
Для этой ситуации `man entr` предлагает следующий пример с модификатором `-d`:

while sleep 1; do ls src/*.rb | entr -d rake; done

то есть при добавлении нового файла или поддиректории `entr` выходит с сообщением и вся цепочка запускается заново

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

Похоже выбора нет, поскольку `entr` ничего не знает об исходных правилах, а получает простой список файлов и директорий. Например, добавили файл `main.cpp` в директорию — нужно его мониторить или нет? Наверное можно сделать более сложную утилиту, которая принимает на вход файловые маски, но это уже вроде как не совсем Unix-way.

Да, решение не универсальное. Если создать subdirectory — entr это, скорее всего, заметит. А subdirectory/newfile — уже нет. Понадобится не однострочник на bash, а полноценный демон на python. Строк на 30:)
Как оно будет работать с набором файлов типа ядра linux, сложно представить :)

rclone умеет работать с другими S3-совместимыми хранилищами из коробки? (с minio тем же)

> с популярными сервисами облачного хранения, включая Amazon S3, Google Drive и Dropbox.

Учитывая, что dropbox сам по себе использует S3, как хранилище — не стоит задаться вопросом об исключении ненужного посредника из цепочки?

А вообще, надо бы накатать LD_PRELOAD библиотеку, вряд ли настолько сложно предотвратить попытки считать нечто несущественное из mtab (и потом, любой интерес облачного сервиса к тому, что, где и как примонтировано — нельзя считать чем-то этичным в принципе).
Только я один ожидал увидеть здесь какую-то лютую магию на С, где прям действительно будет клиент, с авторизацией, файл-хендлингом и остальным реализован? Здесь же по факту клиентом dropbox является rclone, а не скрипт на баше, который его вызывает. Таким же образом можно написать статью о однострочном видеоплерее (где будет в баше вызываться VLC) или куда дальше — однострочном 3D шутере…
В rclone нет отслеживания изменения файлов, однострочник из статьи его добавляет.
Вы, пожалуйста, еще раз внимательно прочитайте заголовок статьи и скажите как это связано с тем, что клиентом к дропбоксу тот скрипт не является? Плюс ко всему этот скрипт одноразовый, это не скрипт демона (демоны на баше пишутся по-другому) и find там вызывается только 1 раз, до следующего перезапуска скрипта…
Ну не совсем так. Здесь, скорее получился «комбайн», ведь rclone не умеет мониторить файлы на изменение. То есть, если продолжать аналогии, то здесь взяли готовую утилиту для оцифровки голоса и готовую утилиту передачи данных (netcat, telnet) и из них сделали «скайп», который может то, что не может каждая отдельная программа.
Из-за наличия find на входе этот демон нужно рестартовать по крону, иначе он не увидит новые файлы. В целом, решение ничем не отличается от «aws s3 sync» по крону.
В чем смысл использования entr если rclone вызывается с параметром sync? Съэкономить пару сотен килобайт на определении того, что появились изменения между локалью и облаком? На мой взгляд, облачные клиенты как раз и заточены на отсылку изменившихся файлов, а не постоянной пересылки всего каталога.
Нет никакого смысла в использовании Entr. Rclone sync прекрасно все умеет делать сам.

В комментариях к статье этого Software Engineering student at the University of Waterloo предложили решения лучше.

Only those users with full accounts are able to leave comments. Log in, please.