Комментарии 57
Помоему это решение может быть контрапродуктивным. Если вы положите тяжёлый файл то есть шанс что синхронизация забьёт канал и будет происходить в 4 раза медленнее и дольше.
Решение должно зависеть от конкретной задачи: сначала — зачем, потом — как. Зачем вам тяжёлый файл в основных 5 ГБ (пересечении синхронизируемого пространства)? Если для этого нет веской причины, помещать его туда нерационально. Скорее всего, тяжёлый файл есть смысл синхронизировать лишь через SkyDrive. Кроме того, Live Mesh и SkyDrive, строго говоря, в этой конструкции довольно опциональны. Совсем не обязательно держать все 4 клиента работающими одновременно. Большую часть времени достаточно Google Drive и Dropbox — они покрывают все основные потребности. А когда канал более свободен, можно подключать и продукты от Microsoft. Сценариев множество, их использование определяют допустимая степерь вовлечённости пользователя и ресурсы текущей рабочей среды.
Ну как зачем… Всё по разному бывает. У меня например может быть очень важная копия SVN. Настолько важная что я не доверю её только одному облаку а буду хранить во всех насколько это возможно.
То есть для вас одновременно важны и сохранность, и скорость передачи на сервер? В этом случае нужно определить приоритет. Вы либо можете сначала синхронизировать одним клиентом (чтобы файл достоверно был сохранён), а затем подключить остальные для резервного копирования, либо потерпеть неудобства, вызванные забитостью канала. В любом случае — это исключительно ваш выбор. Другое дело, что включение/выключение разных клиентов тоже отнимает время и внимание. Здесь нужно искать оптимум.
И еще не совсем понятно как переместить папку MS.
Тоже вижу пока один минус — гонять одни и те же байты по 10 раз. А так — идея интересная.
И это так мы себе упрощаем жизнь?
> длина пути к папке внутри каталога SkyDrive, включая имя файла, не должна превышать 255 символов
Хорошо ещё, что имена 8.3 не требуют.
Хорошо ещё, что имена 8.3 не требуют.
Зачем??
Я вот одного понять не могу, зачем все это?
Резервирование, так при использовании одного сервиса копии есть в облаке и на каждом компе. Зачем их еще резервировать другими сервисами?
Я вот одного понять не могу, зачем все это?
Резервирование, так при использовании одного сервиса копии есть в облаке и на каждом компе. Зачем их еще резервировать другими сервисами?
Игла в яйце, яйцо в утке, утка в зайце, заяц в шоке.)
inception
Опять о Яндекс диске забыли…
Я думаю, стоит задуматься, написать клиент для всех облачных сервисов — т.е. консолидировать всё предоставляемое бесплатно пространство со всех сервисов в один интерфейс — в одну папку. И что б файлы в этой папке распределялись по всем облакам :) Как-то так…
А вообще синхронизация такого рода могла бы стать идеей для стартапа. Юзер заливает свои файлы вам на сервер а вы их синхронизируете со всеми облаками которые юзер захотел. Заодно и клиент облака у юзера будет только один — ваш.
можно было бы сделать так:
Один синхронизирующий клиент, который работает прозрачно для пользователя — один раз задал в этом клиенте настройки всех своих аккаунтов в Google Drive, SkyDrive, Dropbox и т.п., а дальше этот клиент сам выстраивает на всех сервисах идентичную структуру папок. Далее синхронизацию выполняет он сам на основе свободного места на каждом сервисе — скажем, в первую голову забивается дропбокс, затем гугл драйв и т.п. Получится так, что файл будет лежать только на одном из сервисов, но структура директорий на всех сервисах будет единтична. синхронизирующий клиент только пробегает по разрозненной структуре и создает вам иллюзию что она монолитна.
Кто первый берется за реализацию?)
Один синхронизирующий клиент, который работает прозрачно для пользователя — один раз задал в этом клиенте настройки всех своих аккаунтов в Google Drive, SkyDrive, Dropbox и т.п., а дальше этот клиент сам выстраивает на всех сервисах идентичную структуру папок. Далее синхронизацию выполняет он сам на основе свободного места на каждом сервисе — скажем, в первую голову забивается дропбокс, затем гугл драйв и т.п. Получится так, что файл будет лежать только на одном из сервисов, но структура директорий на всех сервисах будет единтична. синхронизирующий клиент только пробегает по разрозненной структуре и создает вам иллюзию что она монолитна.
Кто первый берется за реализацию?)
Такая идея уже проскакивала на хабре :)
НЛО прилетело и опубликовало эту надпись здесь
Хорошо бы, чтобы рабочие станции синхронизировались только с одним облаком. А вами описанная, схема работа на сервере или постоянно включённом устройстве.
Пробовал делать что-то такое на работе. Рабочий компьютер не выключаю. Но через месяц понял, что это совершенно не нужно и попахивает паранойей.
Пробовал делать что-то такое на работе. Рабочий компьютер не выключаю. Но через месяц понял, что это совершенно не нужно и попахивает паранойей.
Возможно, это касается Mesh, он действительно служит лишь для резервного копирования и вероятность реальной востребованности для него крайне мала. Но для остальных сервисов я привёл конкретные аргументы в примере. На текущий момент ни один отдельно взятый продукт не даёт того функционала, который они дают в совокупности. Далее всё зависит от потребностей пользователя. Если вам не нужна интеграция с продуктами Google и Chrome-приложениями, можно спокойно обойтись Dropbox'ом. Если не нужен Linux и публичные ссылки, можно использовать как Google Drive, так и SkyDrive. Приведённая же конструкция ориентирована исключетельно на мои собственные потребности.
А в мою больную голову пришла мысль — если форматы хранения данных на разных сервисах разные, объем разный, есть ограничения разные — почему бы не сделать некое приложение, которе-бы позволило представлять все эти облачные сервисы в виде… ну скажем дисков, блочных устройств, которые я бы мог объединить, ну например, в RAID0 и опубликовать где-то… напрмер на сервере, как iSCSI/Webdav/FTP… и т.д.
Прошел думать над решением.
Прошел думать над решением.
Вас бы попросить диплом мне написать — никак не могу растянуть простейшую идею впаривания IPTV в действующей сети на добрую сотню страниц :) Только 50 выжал…
Извините, но «растягивать простейшие идеи» — не мой конёк. Ежели я и старался быть подробным, то только для убедительности. Если полученный объём кажется вам чрезмерным для прочтения, есть первоначальная краткая версия в Google+: goo.gl/wmfp4
> Устанавливается приложение с наименьшим доступным объёмом — Google Drive. Его папку я разместил в папке Public Dropbox, чтобы иметь возможность получать публичные ссылки на конечные файлы.
Вы осознаёте, что публичные ссылки на конечные файлы может создать любой пользователь?
Написать dl.dropbox.com/u/3442793/Google%20Drive/ и дальше перебирать имена файлов?
То есть ВСЁ, что лежит у вас в Google Drive — публично. Об этом придется во-первых помнить самому, во-вторых Google вполне автоматически туда класть конфиденциальную информацию. Я Google Drive ещё не тестировал, но, как я понял, все личные документы с docs.google.com автоматически попали в этот диск.
Вы осознаёте, что публичные ссылки на конечные файлы может создать любой пользователь?
Написать dl.dropbox.com/u/3442793/Google%20Drive/ и дальше перебирать имена файлов?
То есть ВСЁ, что лежит у вас в Google Drive — публично. Об этом придется во-первых помнить самому, во-вторых Google вполне автоматически туда класть конфиденциальную информацию. Я Google Drive ещё не тестировал, но, как я понял, все личные документы с docs.google.com автоматически попали в этот диск.
Я не вижу для себя серьёзных рисков в этом отношении. Никаких файлов повышенной секретности я не храню (если и храню, то в запароленных контейнерах). А вот быстро получить ссылку на файл для меня бывает катастрофически важно.
Ну не знаю как у вас, но я часто открываю входящий .doc файл из gmail сразу в docs.google.com — если MS Office на машине не установлен, при этом файл автоматически появится в Google Drive. Как по мне — это то же самое, что «Рабочий Стол» положить в папку «Public» дропбокса.
Я уверен в том, что на свете ещё нет человека, который станет подбирать названия файлов в моей публичной папке Dropbox. Как только я заподозрю, что он появился, я усилю меры безопасности.
Интересный график.
наглядно продемонстрирована вступительной диаграммой Эйлера–Венна — это и есть обоснование всего поста. Спасибо.
В свое время отказался от Live Mesh из-за того, что при выгрузке файла после изменения он блокировал чтение файла.
Сейчас ситуация изменилась? И не возникает ли подобных проблем из-за того, что на каждый файл в «ядре» натравлен такой зоопарк?
Сейчас ситуация изменилась? И не возникает ли подобных проблем из-за того, что на каждый файл в «ядре» натравлен такой зоопарк?
Еще может быть полезен сервис Dropbox Automator. Он может раскидывает файлы из вашего DropBox'а по разным хранилищам: GoogleDocs, SkyDrive, BoxNet, Evernote, Picasa, Flickr.
Там, правда, есть ограничение на размер одного файла. Зато свой канал не забивается и запущен должен быть только DropBox.
Там, правда, есть ограничение на размер одного файла. Зато свой канал не забивается и запущен должен быть только DropBox.
Теперь размножать цифровой мусор можно еще проще и быстрее. Производители дисков одобряют.
публичную ссылку, чтобы через неё добавить изображение на Хабр
Гм, а вроде же раньше дропбокс блокировал скачивание файла если к нему много обращались. Помню так какие-то файлы выкладывали в нескольких статьях какое-то время назад, причем просто файлы, которые еще скачать надо, а тут картинка у всех загружается + на главной.
Сглазили.
Полез заменять источник картинки…
Hi Vadim,
This email is an automated notification from Dropbox that your Public links have been temporarily suspended for generating excessive traffic. Your Dropbox will continue to function normally with the exception of Public links.
This suspension is temporary (3 days for the first time).
Please visit Dropbox support if you have any questions.
— The Dropbox Team
Полез заменять источник картинки…
Указал в качестве источника ссылку на опубликованный файл в Google Drive, и картинка снова на Хабре. Модель работает.
> Если третьему лицу известен ваш код пользователя в Dropbox (который можно увидеть в любой вашей публичной ссылке), то у него появляется возможность для перебора имён файлов внутри подкаталогов (названия которых тоже видны в ссылке). Поэтому не рекомендуется помещать в Public важные файлы и необходимо следить, чтобы таковые не были загружены туда автоматически из Google Drive.
Стойте, насколько я понял, дропбокс недавно дал возможность давать прямые ссылки даже на те файлы, которые не находятся в public — в данном случае риск подборки имен файлов внутри каталога тоже существует?
Стойте, насколько я понял, дропбокс недавно дал возможность давать прямые ссылки даже на те файлы, которые не находятся в public — в данном случае риск подборки имен файлов внутри каталога тоже существует?
Не знал об этой возможности. Действительно, появилась такая опция. Вот какую ссылку я получил только что на файл из расшаренной папки: www.dropbox.com/s/dlke16kah1qzke7/Step22.txt Правда, она нерабочая из-за применённой против меня санкции.
Но, судя по виду ссылки, подбор здесь исключён, и это многое меняет. Переход получившего ссылку аналогичен варианту с Public или здесь есть свои нюансы? Кто может рассказать?
Но, судя по виду ссылки, подбор здесь исключён, и это многое меняет. Переход получившего ссылку аналогичен варианту с Public или здесь есть свои нюансы? Кто может рассказать?
Нет, для каждого объекта (будь то файл или целая папка) путь содержит случайный набор 15 символов + имя файла.
Маленький hint. Если у вас в DropBox доступно больше места, чем в Ubuntu One то просто создайте симлинк на папку Ubuntu One в папке Dropbox.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сквозная облачность