Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Облачная синхронизация шифрованных контейнеров
3 views
Skip to first unread message
Dmitry Bakhrov
Nov 3, 2017, 3:14:59 PM11/3/17
to
Hello, All!
Простите за почти кросспост письма из ru.windows.xp, но это не совсем
кросспост, да и сюда, как погляжу, никто не пишет, будет повод оживить
эху ;)
Какие из облачных сервисов пригодны для сабжа, разумеется, в рамках
эхотага. Более развёрнуто опишу ниже.
Есть у меня шифрованный контейнер веракрипта, размером 6 гб.
Пользоваться им надо дома и на работе. Для этой цели я выложил его на
dropbox и всё чудесно работает: на работе изменил нужные данные,
отмонтировал, dropbox проиндексировал контейнер и выгрузил в облако
только изменённые файлы. Выгружает он блоками по 4 кб, тоесть, если я,
к примеру, отредактировал 1 кб текста, в облако у меня зальётся всего
4 кб, столько же и дома скачается из облака, когда домашний клиент
начнёт синхронизацию. Место в Dropbox кончается, покупать жаба душит,
а синхронизировать контейнер, который только разрастается, надо. Есть
у меня аккаунт на mega.nz на 50 гб, почти 300 гб на я диске и
несколько терабайтных облаков на майлрушечке, но вот беда: на момент,
когда я пробовал, не я диск, не клиент облака мылру не умел
индексировать файлы, что в случае с шифрованным контейнером выливалось
вот во что:
* Если в настройках веракрипта включена опция "не изменять время
доступа к файлу" что для секурности вполне ничего, то клиент вообще не
синхронизирует шифрованный контейнер, ну тоесть, даты файлов не
изменились, изменений нет;
* если время последнего доступа изменилось, клиент начинает заливать в
облако весь том заново, тоесть в случае правки 1 кб текста получим
заливку 6 гб в облако на работе и скачивание 6 гб из облака дома, что
как-то совсем некошерно. Про отсутствие контроля версий я уже молчу,
пару раз оно меня здорово спасало, один раз контейнер перестал
монтироваться, а второй раз удалил лишний файл, а вспомнил, когда оно
уже синхронизировалось.
Hу а вопрос коротенький, вдруг кто-то, как и я, решал подобные
вопросы: какой сервис посоветуете, а, быть может, mega это умеет, у
них, кстати, вроде бы и контроль версий есть.
--
Regards, Dmitry
Простите за почти кросспост письма из ru.windows.xp, но это не совсем
кросспост, да и сюда, как погляжу, никто не пишет, будет повод оживить
эху ;)
Какие из облачных сервисов пригодны для сабжа, разумеется, в рамках
эхотага. Более развёрнуто опишу ниже.
Есть у меня шифрованный контейнер веракрипта, размером 6 гб.
Пользоваться им надо дома и на работе. Для этой цели я выложил его на
dropbox и всё чудесно работает: на работе изменил нужные данные,
отмонтировал, dropbox проиндексировал контейнер и выгрузил в облако
только изменённые файлы. Выгружает он блоками по 4 кб, тоесть, если я,
к примеру, отредактировал 1 кб текста, в облако у меня зальётся всего
4 кб, столько же и дома скачается из облака, когда домашний клиент
начнёт синхронизацию. Место в Dropbox кончается, покупать жаба душит,
а синхронизировать контейнер, который только разрастается, надо. Есть
у меня аккаунт на mega.nz на 50 гб, почти 300 гб на я диске и
несколько терабайтных облаков на майлрушечке, но вот беда: на момент,
когда я пробовал, не я диск, не клиент облака мылру не умел
индексировать файлы, что в случае с шифрованным контейнером выливалось
вот во что:
* Если в настройках веракрипта включена опция "не изменять время
доступа к файлу" что для секурности вполне ничего, то клиент вообще не
синхронизирует шифрованный контейнер, ну тоесть, даты файлов не
изменились, изменений нет;
* если время последнего доступа изменилось, клиент начинает заливать в
облако весь том заново, тоесть в случае правки 1 кб текста получим
заливку 6 гб в облако на работе и скачивание 6 гб из облака дома, что
как-то совсем некошерно. Про отсутствие контроля версий я уже молчу,
пару раз оно меня здорово спасало, один раз контейнер перестал
монтироваться, а второй раз удалил лишний файл, а вспомнил, когда оно
уже синхронизировалось.
Hу а вопрос коротенький, вдруг кто-то, как и я, решал подобные
вопросы: какой сервис посоветуете, а, быть может, mega это умеет, у
них, кстати, вроде бы и контроль версий есть.
--
Regards, Dmitry
Eugene Sharov
Nov 3, 2017, 4:54:59 PM11/3/17
to
Привет, Dmitry!
03 ноя 17 21:57, Dmitry Bakhrov -> All:
DB> Какие из облачных сервисов пригодны для сабжа, разумеется, в рамках
DB> эхотага. Более развёрнуто опишу ниже.
Знаешь, чувак, я тебе, возможно, сейчас скажу страшную ересь не только с точки
зрения эхотага, но и с точки зрения более старших товарищей, которые меня
немедленно закидают ссаными тапками.
Да и с твоей.
Тем не менее.
Первое, что меня смущает - сам подход к воросу. Качать тудой-сюдой весь
контейнер, имхо, не самая лучшая мысль. Инкрементальность спасает до поры до
времени, в некий, не самый счастливый для тебя день, вполне может понадобиться
синхронизация всего контейнера (достаточно жирного, если я правильно понял твоё
описание задачи). Теорию объяснить или сам понимаешь?
Во-вторых - ты уверен, что тебе нужен именно шифрованый контейнер? Не проще
изменить сам подход к задаче? По большому счёту тебе нужна, если я првильно
понял, файлопомойка с версионностью и шифрованием на обеих сторонах и между. И
даже версионность под вопросом.
Ну а в-третьих - посмотри на ЯД. Там случаются акции, позволяющие расширить
пространство до 30-40 гиг бесплатно и не особо напрягаясь. Правда, не уверен
насчёт инкрементальности, тупо не проверял по причине "напрочь не надо", зато
скорость довольно высокая.
Но, повторюсь, лучше пересмотреть сам подход.
BTW, у rsync, вроде как, есть имплементация под винду. VPN ни кто не отменял
(правительство пытается, но в другом смысле). Да и вообще, зачастую собственный
сервис обходится далеко не так уж и затратно по финансам и/или расходам времени
и сил.
OffTop: У меня похожая задача решается тупо по SFTP + планировщик задач + cron,
без каких либо дополнительных наворотов или 3rd party, максимум - самописные
скрипты bash и cmd. Да, на серверной стороне неэхотажный дебиан. Сам сервак
собран по принципу "я тебя слепила из того что было" и стоит на балконе, чтобы
шумом кулера не мешать спать. Подумай на эту тему.
С наилучшими пожеланиями, Eugene.
*В эфире:* Albert Collins - A Good Fool Is Hard To Find
... Я знал, что молчание - золото, но я предпочёл серебро (Ю.Наумов)
03 ноя 17 21:57, Dmitry Bakhrov -> All:
DB> Какие из облачных сервисов пригодны для сабжа, разумеется, в рамках
DB> эхотага. Более развёрнуто опишу ниже.
Знаешь, чувак, я тебе, возможно, сейчас скажу страшную ересь не только с точки
зрения эхотага, но и с точки зрения более старших товарищей, которые меня
немедленно закидают ссаными тапками.
Да и с твоей.
Тем не менее.
Первое, что меня смущает - сам подход к воросу. Качать тудой-сюдой весь
контейнер, имхо, не самая лучшая мысль. Инкрементальность спасает до поры до
времени, в некий, не самый счастливый для тебя день, вполне может понадобиться
синхронизация всего контейнера (достаточно жирного, если я правильно понял твоё
описание задачи). Теорию объяснить или сам понимаешь?
Во-вторых - ты уверен, что тебе нужен именно шифрованый контейнер? Не проще
изменить сам подход к задаче? По большому счёту тебе нужна, если я првильно
понял, файлопомойка с версионностью и шифрованием на обеих сторонах и между. И
даже версионность под вопросом.
Ну а в-третьих - посмотри на ЯД. Там случаются акции, позволяющие расширить
пространство до 30-40 гиг бесплатно и не особо напрягаясь. Правда, не уверен
насчёт инкрементальности, тупо не проверял по причине "напрочь не надо", зато
скорость довольно высокая.
Но, повторюсь, лучше пересмотреть сам подход.
BTW, у rsync, вроде как, есть имплементация под винду. VPN ни кто не отменял
(правительство пытается, но в другом смысле). Да и вообще, зачастую собственный
сервис обходится далеко не так уж и затратно по финансам и/или расходам времени
и сил.
OffTop: У меня похожая задача решается тупо по SFTP + планировщик задач + cron,
без каких либо дополнительных наворотов или 3rd party, максимум - самописные
скрипты bash и cmd. Да, на серверной стороне неэхотажный дебиан. Сам сервак
собран по принципу "я тебя слепила из того что было" и стоит на балконе, чтобы
шумом кулера не мешать спать. Подумай на эту тему.
С наилучшими пожеланиями, Eugene.
*В эфире:* Albert Collins - A Good Fool Is Hard To Find
... Я знал, что молчание - золото, но я предпочёл серебро (Ю.Наумов)
Dmitry Bakhrov
Nov 4, 2017, 2:54:59 AM11/4/17
to
Hello, Eugene!
You wrote to Dmitry Bakhrov Saturday, November 4, 2017, 6:03:06 AM:
ES> Первое, что меня смущает - сам подход к воросу. Качать
ES> тудой-сюдой весь контейнер, имхо, не самая лучшая мысль.
Именно поэтому я и использую Dropbox. После размонтирования контейнера
он индексирует файл и заливает на облако только то, что в этом файле
изменилось, что более, чем устраивает, учитывая, что меняется обычно
не очень много, а скорость инета на работе не самая быстрая. ЯД и
Cl...@mail.ru же на момент тестирования, как я и писал, тупо "не
видели" изменений, если дата файла не менялась, или заливали в облако
все 6 гб, если дата менялась.
ES> Инкрементальность спасает до поры до времени, в некий, не самый
ES> счастливый для тебя день, вполне может понадобиться синхронизация
ES> всего контейнера (достаточно жирного, если я правильно понял твоё
ES> описание задачи).
Hе вижу большой проблемы в этом. Если по каким-либо причинам контейнер
разрушится, заходим в веб-морду dropbox и откатываемся на любую версию
контейнера за последние 30 дней. Уж за 30 дней, учитывая, что 5 дней в
неделю я работаю, я смогу понять, что с данными что-то не то, и смогу
сделать Rolback с минимальными потерями
ES> Теорию объяснить или сам понимаешь?
Если честно, не очень, так что, если объяснишь, буду благодарен. :)
ES> Во-вторых - ты уверен, что тебе нужен именно шифрованый
ES> контейнер?
Hа работе, да. Hужно скрыть факт существования некоторых данных не
только от коллег, которые чисто теоретически могут работать на моей же
машине, например, когда я в отпуске, но и, что важнее, от различных
проверяющих органов, которым вряд-ли что-то скажет название файла
nu_pogodi_dvd.iso, лежащем в %userprofile%\dropbox, а, если и наведёт
на подозрение, то узнать, что же хранится в этом файле без серьёзного
физического на меня воздействия, скорее всего, не получится.
ES> Hе проще изменить сам подход к задаче?
В данном случае, не совсем вижу, как это сделать.
ES> По большому
ES> счёту тебе нужна, если я првильно понял, файлопомойка с
ES> версионностью и шифрованием на обеих сторонах
Если бы я, к примеру, синхронизовал стационарник и ноут, то было бы
достаточно шифрованной передачи данных на тот же nas, который стоит
дома, но в данном случае, боюсь, без контейнера не обойтись.
ES> и между. И даже версионность под вопросом.
Увы, случается ситуация, что сегодня начальство требует одно, завтра
говорит переделывай, а после завтра, мол, слушай, надо, как было
позавчера, а то,что вчера делал выкинь в помойку, вот тут очень
спасает контроль версий и быстрый rolback на позавчера. Да, можно
просто сохранять много версий, в конце концов поставить какую-нить
штуку для контроля версий, чем и придётся заморочиться, если с наскока
не получится ничего найти.
ES> Hу а в-третьих - посмотри на ЯД. Там случаются акции, позволяющие
ES> расширить пространство до 30-40 гиг бесплатно и не особо
ES> напрягаясь.
А ведь в прошлом письме я писал про это, вот, что я писал:
Есть у меня аккаунт на mega.nz на 50 гб, почти 300 гб на я диске и
несколько терабайтных облаков на майлрушечке, но вот беда: на момент,
когда я пробовал, не я диск, не клиент облака мылру не умел
индексировать файлы, что в случае с шифрованным контейнером выливалось
вот во что:
* Если в настройках веракрипта включена опция "не изменять время
доступа к файлу" что для секурности вполне ничего, то клиент вообще не
синхронизирует шифрованный контейнер, ну тоесть, даты файлов не
изменились, изменений нет;
* если время последнего доступа изменилось, клиент начинает заливать в
облако весь том заново, тоесть в случае правки 1 кб текста получим
заливку 6 гб в облако на работе и скачивание 6 гб из облака дома, что
как-то совсем некошерно. Про отсутствие контроля версий я уже молчу,
Как раз я про то и говорил, что никто, кроме dropbox не умеет
выгружать в облако только ту часть контейнера, которая изменилась, все
тупо льют весь контейнер, или вообще ничего не льют.
--
Regards, Dmitry
You wrote to Dmitry Bakhrov Saturday, November 4, 2017, 6:03:06 AM:
ES> Первое, что меня смущает - сам подход к воросу. Качать
ES> тудой-сюдой весь контейнер, имхо, не самая лучшая мысль.
Именно поэтому я и использую Dropbox. После размонтирования контейнера
он индексирует файл и заливает на облако только то, что в этом файле
изменилось, что более, чем устраивает, учитывая, что меняется обычно
не очень много, а скорость инета на работе не самая быстрая. ЯД и
Cl...@mail.ru же на момент тестирования, как я и писал, тупо "не
видели" изменений, если дата файла не менялась, или заливали в облако
все 6 гб, если дата менялась.
ES> Инкрементальность спасает до поры до времени, в некий, не самый
ES> счастливый для тебя день, вполне может понадобиться синхронизация
ES> всего контейнера (достаточно жирного, если я правильно понял твоё
ES> описание задачи).
Hе вижу большой проблемы в этом. Если по каким-либо причинам контейнер
разрушится, заходим в веб-морду dropbox и откатываемся на любую версию
контейнера за последние 30 дней. Уж за 30 дней, учитывая, что 5 дней в
неделю я работаю, я смогу понять, что с данными что-то не то, и смогу
сделать Rolback с минимальными потерями
ES> Теорию объяснить или сам понимаешь?
Если честно, не очень, так что, если объяснишь, буду благодарен. :)
ES> Во-вторых - ты уверен, что тебе нужен именно шифрованый
ES> контейнер?
Hа работе, да. Hужно скрыть факт существования некоторых данных не
только от коллег, которые чисто теоретически могут работать на моей же
машине, например, когда я в отпуске, но и, что важнее, от различных
проверяющих органов, которым вряд-ли что-то скажет название файла
nu_pogodi_dvd.iso, лежащем в %userprofile%\dropbox, а, если и наведёт
на подозрение, то узнать, что же хранится в этом файле без серьёзного
физического на меня воздействия, скорее всего, не получится.
ES> Hе проще изменить сам подход к задаче?
В данном случае, не совсем вижу, как это сделать.
ES> По большому
ES> счёту тебе нужна, если я првильно понял, файлопомойка с
ES> версионностью и шифрованием на обеих сторонах
Если бы я, к примеру, синхронизовал стационарник и ноут, то было бы
достаточно шифрованной передачи данных на тот же nas, который стоит
дома, но в данном случае, боюсь, без контейнера не обойтись.
ES> и между. И даже версионность под вопросом.
Увы, случается ситуация, что сегодня начальство требует одно, завтра
говорит переделывай, а после завтра, мол, слушай, надо, как было
позавчера, а то,что вчера делал выкинь в помойку, вот тут очень
спасает контроль версий и быстрый rolback на позавчера. Да, можно
просто сохранять много версий, в конце концов поставить какую-нить
штуку для контроля версий, чем и придётся заморочиться, если с наскока
не получится ничего найти.
ES> Hу а в-третьих - посмотри на ЯД. Там случаются акции, позволяющие
ES> расширить пространство до 30-40 гиг бесплатно и не особо
ES> напрягаясь.
А ведь в прошлом письме я писал про это, вот, что я писал:
Есть у меня аккаунт на mega.nz на 50 гб, почти 300 гб на я диске и
несколько терабайтных облаков на майлрушечке, но вот беда: на момент,
когда я пробовал, не я диск, не клиент облака мылру не умел
индексировать файлы, что в случае с шифрованным контейнером выливалось
вот во что:
* Если в настройках веракрипта включена опция "не изменять время
доступа к файлу" что для секурности вполне ничего, то клиент вообще не
синхронизирует шифрованный контейнер, ну тоесть, даты файлов не
изменились, изменений нет;
* если время последнего доступа изменилось, клиент начинает заливать в
облако весь том заново, тоесть в случае правки 1 кб текста получим
заливку 6 гб в облако на работе и скачивание 6 гб из облака дома, что
как-то совсем некошерно. Про отсутствие контроля версий я уже молчу,
выгружать в облако только ту часть контейнера, которая изменилась, все
тупо льют весь контейнер, или вообще ничего не льют.
--
Regards, Dmitry
Eugene Sharov
Nov 4, 2017, 8:55:00 AM11/4/17
to
Привет, Dmitry!
04 ноя 17 09:35, Dmitry Bakhrov -> Eugene Sharov:
DB> ЯД и Cl...@mail.ru же на момент тестирования, как я и писал, тупо "не
DB> видели" изменений, если дата файла не менялась, или заливали в облако
DB> все 6 гб, если дата менялась.
Извини, проглядел. Ну, зато ты ответил на давно интересующий меня вопрос :) ЯД
не проверяет файлы по содержимому.
ES>> Теорию объяснить или сам понимаешь?
DB> Если честно, не очень, так что, если объяснишь, буду благодарен. :)
Ну, смотри, контейнер, если сильно упростить, представлят собой зашифрованный
образ диска. Пока ты редактируешь файл, и новый размер файла не первышает
размер кластера, изменяется только кусочек образа. Как только размер файла
превысит размер кластера... Вот лично я не знаю, как поведет себя "Вера" в этой
ситуации. Возможно - сделает новый фрагмент, который допишет в конец
контейнера, и тогда мы опять получаем возможность обновить образ инкрементльно.
А возможен и другой вариант - все данные после нашего файла сдвинутся, т.е.
"поплывёт" информация начиная от файла и дальше до конца контейнера. Если файл
находится в начале образа... Ну, ты понял.
DB> Hужно скрыть факт существования некоторых данных
Вот это - ключевой момент, значительно осложняющий задачу.
ES>> Hе проще изменить сам подход к задаче?
DB> В данном случае, не совсем вижу, как это сделать.
Вот я, признаться, тоже :)
Единственная альтернатива - синхронизировать не сам контейнер а именно его
содержимое, пофайлово. Дома тебе секретность не нужна, а на работе...
В прицнипе, я не знаю, как поведёт себя клиет дропа или того же ЯДа, если
контейнер не смонтирован в момент синхронизации. Но файлики, которые он будет
пытаться синхронизировать, наверняка будут явно заметны в клиенте. Тут покажут
только эксперименты. Если любой клиент, не важно - ЯД, drop, mail, rsync сможет
подождать подключения диска, и при этом не будет истерично верещать "ай, не
могу скопировать файл "ВОТ СЮДА СПЕЦСЛУЖБАМ НЕ СМОТРЕТЬ.pdf", то вполне
вариант. Опять же, желательно, чтобы клиент по клику не показывал содержимое
облачного хранилища (по крайней мере - без ввода логина/пароля). Тут только
экспериментировать.
Покопай вcё же в сторону rsync. Утилита изначально линуховая, т.е. консольная,
её вывод наверняка можно подавить. Ну будет у тебя на машине ещё один сервис
болтаться, кто их считает.
А больше даже не знаю, что и посоветовать.
С наилучшими пожеланиями, Eugene.
*В эфире:* Ministry - Lava
04 ноя 17 09:35, Dmitry Bakhrov -> Eugene Sharov:
DB> ЯД и Cl...@mail.ru же на момент тестирования, как я и писал, тупо "не
DB> видели" изменений, если дата файла не менялась, или заливали в облако
DB> все 6 гб, если дата менялась.
Извини, проглядел. Ну, зато ты ответил на давно интересующий меня вопрос :) ЯД
не проверяет файлы по содержимому.
ES>> Теорию объяснить или сам понимаешь?
Ну, смотри, контейнер, если сильно упростить, представлят собой зашифрованный
образ диска. Пока ты редактируешь файл, и новый размер файла не первышает
размер кластера, изменяется только кусочек образа. Как только размер файла
превысит размер кластера... Вот лично я не знаю, как поведет себя "Вера" в этой
ситуации. Возможно - сделает новый фрагмент, который допишет в конец
контейнера, и тогда мы опять получаем возможность обновить образ инкрементльно.
А возможен и другой вариант - все данные после нашего файла сдвинутся, т.е.
"поплывёт" информация начиная от файла и дальше до конца контейнера. Если файл
находится в начале образа... Ну, ты понял.
DB> Hужно скрыть факт существования некоторых данных
Вот это - ключевой момент, значительно осложняющий задачу.
ES>> Hе проще изменить сам подход к задаче?
Вот я, признаться, тоже :)
Единственная альтернатива - синхронизировать не сам контейнер а именно его
содержимое, пофайлово. Дома тебе секретность не нужна, а на работе...
В прицнипе, я не знаю, как поведёт себя клиет дропа или того же ЯДа, если
контейнер не смонтирован в момент синхронизации. Но файлики, которые он будет
пытаться синхронизировать, наверняка будут явно заметны в клиенте. Тут покажут
только эксперименты. Если любой клиент, не важно - ЯД, drop, mail, rsync сможет
подождать подключения диска, и при этом не будет истерично верещать "ай, не
могу скопировать файл "ВОТ СЮДА СПЕЦСЛУЖБАМ НЕ СМОТРЕТЬ.pdf", то вполне
вариант. Опять же, желательно, чтобы клиент по клику не показывал содержимое
облачного хранилища (по крайней мере - без ввода логина/пароля). Тут только
экспериментировать.
Покопай вcё же в сторону rsync. Утилита изначально линуховая, т.е. консольная,
её вывод наверняка можно подавить. Ну будет у тебя на машине ещё один сервис
болтаться, кто их считает.
А больше даже не знаю, что и посоветовать.
С наилучшими пожеланиями, Eugene.
*В эфире:* Ministry - Lava
Eugene Sharov
Nov 4, 2017, 9:05:00 AM11/4/17
to
Привет, Dmitry!
04 ноя 17 09:35, Dmitry Bakhrov -> Eugene Sharov:
DB> ЯД и Cl...@mail.ru же на момент тестирования, как я и писал, тупо "не
DB> видели" изменений, если дата файла не менялась, или заливали в облако
DB> все 6 гб, если дата менялась.
Извини, проглядел. Ну, зато ты ответил на давно интересующий меня вопрос :) ЯД
не проверяет файлы по содержимому.
04 ноя 17 09:35, Dmitry Bakhrov -> Eugene Sharov:
DB> ЯД и Cl...@mail.ru же на момент тестирования, как я и писал, тупо "не
DB> видели" изменений, если дата файла не менялась, или заливали в облако
DB> все 6 гб, если дата менялась.
Извини, проглядел. Ну, зато ты ответил на давно интересующий меня вопрос :) ЯД
не проверяет файлы по содержимому.
ES>> Теорию объяснить или сам понимаешь?
DB> Если честно, не очень, так что, если объяснишь, буду благодарен. :)
Ну, смотри, контейнер, если сильно упростить, представлят собой зашифрованный
образ диска. Пока ты редактируешь файл, и новый размер файла не первышает
размер кластера, изменяется только кусочек образа. Как только размер файла
превысит размер кластера... Вот лично я не знаю, как поведет себя "Вера" в этой
ситуации. Возможно - сделает новый фрагмент, который допишет в конец
контейнера, и тогда мы опять получаем возможность обновить образ инкрементльно.
А возможен и другой вариант - все данные после нашего файла сдвинутся, т.е.
"поплывёт" информация начиная от файла и дальше до конца контейнера. Если файл
находится в начале образа... Ну, ты понял.
DB> Hужно скрыть факт существования некоторых данных
Вот это - ключевой момент, значительно осложняющий задачу.
Ну, смотри, контейнер, если сильно упростить, представлят собой зашифрованный
образ диска. Пока ты редактируешь файл, и новый размер файла не первышает
размер кластера, изменяется только кусочек образа. Как только размер файла
превысит размер кластера... Вот лично я не знаю, как поведет себя "Вера" в этой
ситуации. Возможно - сделает новый фрагмент, который допишет в конец
контейнера, и тогда мы опять получаем возможность обновить образ инкрементльно.
А возможен и другой вариант - все данные после нашего файла сдвинутся, т.е.
"поплывёт" информация начиная от файла и дальше до конца контейнера. Если файл
находится в начале образа... Ну, ты понял.
DB> Hужно скрыть факт существования некоторых данных
Вот это - ключевой момент, значительно осложняющий задачу.
ES>> Hе проще изменить сам подход к задаче?
DB> В данном случае, не совсем вижу, как это сделать.
Вот я, признаться, тоже :)
Единственная альтернатива - синхронизировать не сам контейнер а именно его
содержимое, пофайлово. Дома тебе секретность не нужна, а на работе...
В прицнипе, я не знаю, как поведёт себя клиет дропа или того же ЯДа, если
контейнер не смонтирован в момент синхронизации. Но файлики, которые он будет
пытаться синхронизировать, наверняка будут явно заметны в клиенте. Тут покажут
только эксперименты. Если любой клиент, не важно - ЯД, drop, mail, rsync сможет
подождать подключения диска, и при этом не будет истерично верещать "ай, не
могу скопировать файл "ВОТ СЮДА СПЕЦСЛУЖБАМ НЕ СМОТРЕТЬ.pdf", помогите!", то
Вот я, признаться, тоже :)
Единственная альтернатива - синхронизировать не сам контейнер а именно его
содержимое, пофайлово. Дома тебе секретность не нужна, а на работе...
В прицнипе, я не знаю, как поведёт себя клиет дропа или того же ЯДа, если
контейнер не смонтирован в момент синхронизации. Но файлики, которые он будет
пытаться синхронизировать, наверняка будут явно заметны в клиенте. Тут покажут
только эксперименты. Если любой клиент, не важно - ЯД, drop, mail, rsync сможет
подождать подключения диска, и при этом не будет истерично верещать "ай, не
Dmitry Bakhrov
Nov 5, 2017, 4:05:00 PM11/5/17
to
Hello, Eugene!
You wrote to Dmitry Bakhrov Saturday, November 4, 2017, 10:20:22 PM:
ES> Покопай вcё же в сторону rsync. Утилита изначально линуховая,
ES> т.е. консольная, её вывод наверняка можно подавить. Hу будет у
ES> тебя на машине ещё один сервис болтаться, кто их считает.
Спасибо, посмотрю, благодарю за дельный совет.
--
Regards, Dmitry
You wrote to Dmitry Bakhrov Saturday, November 4, 2017, 10:20:22 PM:
ES> Покопай вcё же в сторону rsync. Утилита изначально линуховая,
ES> т.е. консольная, её вывод наверняка можно подавить. Hу будет у
ES> тебя на машине ещё один сервис болтаться, кто их считает.
Спасибо, посмотрю, благодарю за дельный совет.
--
Regards, Dmitry
0 new messages