Comments 57
Всё верно, поддержку авторизации по нескольким аккаунтам сделать несложно. Потом нужно ввести балансировку файлов по разным аккаунтам с нормальный распределением. Ну и да, это всё если маилру ещё не забанят вас за твинководство на этапе тестирования ;)
А по поводу балансировки, я думал можно разбить файл но количество аккаунтов и залить в каждый по кусочку
Можно и так, верно, полезно было бы как раз для крупных файлов > 2 Гб, после разбивки их не пришлось бы распиливать как сейчас.
Если учетку могут заблокировать, то нельзя файлы распределять — заблокируют одну учетку, а потеряются все файлы.
Судя по манам mhddfs, он пишет на один диск пока там не закончится место, и только потом переключается на следующий:
При записи файлов в файловую систему файлы пишутся на первый hdd до
тех пор пока там есть место (см опцию mlimit), затем они пишутся на
второй hdd, третий итп.
Балансировка в данном случае не сильно нужна… Потому что если на 2 облака писать одно и то же. Или на 2 облака писать с одного и того же ip — подозрительно как-то...
А на счёт работоспособности mhddfs могу сказать так: работает отлично) Вот я у себя запустил такое интересное сочетание, и оно работает! Правда память отжирает… Но с памятью могут проблемы из-за доступа программы к файлам в /tmp… Хотя туда вроде как писать можно всем и всё.
А вообще было бы неплохо, на самом деле, с балансировкой то. А на счёт твинководства… Можно через tor попробовать пустить весь трафик)
О, напишите пример использования, если вас не затруднит? Я добавлю в README.
Кроме того пример использования и не нужен, достаточно отсылки: «для объединения нескольких аккаунтов можете использовать mhddfs, UnionFS или Aufs». Если по справке этих технологий нельзя быстро понять, как ими пользоваться, то это их маны нужно улучшать, а не раздувать ридми вашего проекта.
Сам пользуюсь вариантом, схожим с таким: https://enztv.wordpress.com/2016/10/19/using-amazon-cloud-drive-with-plex-media-server-and-encrypting-it/ Часть его решений в том или ином виде применяю с некоторыми доработками.
Да, тоже в основном для Plex. Использую безлимитный GDrive, ACD тоже, например. Объем данных — десятки терабайт. Думаю, что после половины петабайта насыщение произойдет и больше не нужно будет, поглядим. Начну еще больше внимания уделять отказоустойчивости. Сейчас только три копии в разных концах планеты. Важно все это дело использовать только для себя и не шэрить, тем более с доходом. Просто на всякий случай.
Проблема в том, что config.json пока что только один… А в нём, как я понял из того, что видел в readme, не поддерживается несколько файловых систем за раз. Поэтому придётся писать какой-то свой скрипт, который будет в несколько команд включать сначала marcfs, а потом их объединять с помощью того же mhddfs.
Ну да, нужно будет автоматизировать монтирование всего добра в нужном порядке. Но и без того автор предлагал бутерброд из MARC-FS + encfs, добавляется только один слой.
Автоматизировать монтирование в нужном порядке в современных реалиях видимо правильнее через systemd. А умеючи и удобнее.
Я думаю вы сами согласитесь, что танцы с бубном переменными $HOME — не лучшая идея.
бутерброд из MARC-FS + encfs, добавляется только один слой.
Ну тут палка о двух концах. Да, если мне нужно будет 2 облачка в одно сливать, то это красиво, но если я порядочный гражданин, который имеет только 1 акк у майла? Мне кажется, что лучше уж пусть закононепослушные, типа меня, будут сами объединять несколько marcfs с помощью того же mhddfs, чем заставлять человека писать ещё один велосипед.
А вот сделать в marcfs возможность из одного конфига делать много точек монтирования — будет очень полезной.
Я, скорее, добавлю поддержку $XDG_CONFIG_DIR, так что не придётся менять целиком $HOME. Или того лучше, сделаю опцию --config=/path/to/conf
Я думаю вы сами согласитесь, что танцы с бубном переменными $HOME — не лучшая идея.
Да, но это лучше, чем последовательно скриптом запускать разные инстансы монтирования, перед каждым очередным запуском вписывая в config.json разные значения.
Мне кажется, что лучше уж пусть закононепослушные, типа меня, будут сами объединять несколько marcfs с помощью того же mhddfs, чем заставлять человека писать ещё один велосипед.
Если под человеком, которому писать велосипед, подразумевался Kanedias, то это полностью совпадает с моим отношением к ситуации.
А вот сделать в marcfs возможность из одного конфига делать много точек монтирования — будет очень полезной.
Я больше голосую за возможность указать путь к конфигу параметром командной строки.
Да, человек именно Kanedias...
Вообще да, получается, что хорошим людям вообще не нужно знать о том, что можно несколько систем делать, тогда наличие флага пути к файлу конфигурации и текущая функциональность этого файла конфигурации уже достаточна.
А у меня вопрос есть, тупой скорее всего, но всё же. В Readme сказано, что нужно сначала отмонтировать прошлую encfs, из этого я делаю вывод, что работать с несколькими примонтированными системами я не могу. Это я делаю правильный вывод или нет?
А почему бы просто не смонтировать облако mail.ru в davFS, и EncFS создать внутри точки монтирования davFS? Mail.ru не поддерживает webdav? Или encFS так просто внутри davFS не работает?
То есть файлы, имеющие одинаковые хэши и размеры, хранятся в некоем общем пуле, а пользователям после закачки просто добавляется "хардлинк" на них.
Хеш считается уже в облаке или на локальном клиенте?
Если на клиенте то нет смысла передавать в облако файл который там уже есть. А в таком случае можно "загрузить" в облако файл от которого у тебя только хеш и размер и забрать его оттуда.
Скорее всего на сервере, иначе можно было бы украсть файл, не имея содержимое, а имея только его хеш...
Копирование это не кража. Но на клиенте же выгодней. Кроме хеша и размера ничего передавать тогда не надо.
Для майла конечно же выгодней, но сами подумайте.
Вот у вас есть фотографии с вашей половинкой (просто для примера), которые Вам памятны, и Вы не хотите это передавать другим ну вообще никаким макаром, потому что это ваше личное дело.
А я, вот такой крутой хакер, взял, сгенерировал хеш случайным образом, и попал именно на Вас и именно на эти фотографии...
А если брать по чесноку, то сейчас есть много дебилов, которые отправляют какие-нибудь важные документы через облака… А так же бекапы, которые вообще-то зашифрованы обычно ключём, но хеш можно узнать на сервере, ведь много проще сидеть спокойно дома и качать с майла, чем через ssh тунель, да и шансов спалиться в разы меньше.
Короче, если хеш вычисляется на клиенте, то это потенциальная дыра в безопасности.
Окей, тогда вопрос, вот я посчитал хеш, отправил, и оказался уже такой файл в облаке. Что сервер будет делать? Файл то изначально не мой… Заставлять качать файл и потом разрешать мне доступ на тот, который уже есть?
Короче говоря, легче и безопаснее сделать это на стороне сервера, учитывая, что облако майла изначально работает по стандартному http, то там и не может быть каких-то изысков.
Но в целом, я согласен, что легче все манипуляции сделать на стороне сервера.
Хэш считается на облаке, после заливки.
Пара камментов:
* не указана версия GPL (а еще лучше — положить в гитхаб текст лицензии — это как бы «прилично»)
* бы еще в README.md добавить requirements — что нужно для сборки; понятно, что по сообщениям cmake можно сделать некие выводы — но довольно сложно (например libcurl-devel, fuse-devel, jsoncpp-devel, jemalloc-devel для RH-based)
* еще можно напилить примочку для mc — там не совсем fuse, поэтому оверхед должен быть меньше.
* ну и зарелизить, что ли :-)
Самое важное-то и забыл! Спасибо! Лицензия GPLv3.
бы еще в README.md добавить requirements — что нужно для сборки
Я все комментарии с этой темы к себе понемногу в TODO переношу, как вынырну в очередной раз из работы и релизов, сделаю вики. Пока что можно посмотреть зависимости для наиболее популярных дистрибутивов в gitlab-CI скрипте
Пробовал Яндекс.Диск через davfs, но кеширование, которое ещё и оставляет недокачанные куски, убивает всю вкусность WEBDAV.
Насколько просто исключить шифрование из вашего кода?
Опакетил для Archlinux: marcfs-git
Привет, Автор. Скажи пожалуйста, а почему может быть так медленно? mc показывает корневую папку облака через минуту, хотя интернет у меня хороший и официальный клиент под маком нормально работает. Коннекчусь так:
marcfs MYDIR -o max-download-rate=30,max-upload-rate=1,cachedir=MYDIR.cache,username=MYEMAIL,password=MYPASSWORD
MYDIR -- абсолютный путь.
Облако.Mail.Ru + EncFS без локального хранения файлов