Вопрос такой..

Насколько я знаю, весь.

Весь.

(1)(2) Как проверяли? FAQ Dropbox-а(и моя практика) говорит об обратном: https://www.dropbox.com/help/8/en

https://www.dropbox.com/help/8/ru - даже так лучше.

(4) оттуда:
"Для опытных пользователей

Хотите подробности? Тогда вот:

Перед передачей файла мы сравниваем его последнюю и предыдущую версии..."

и как часто версионирование происходит?

или сравнивает локальную версию с сетевой? тогда один х надо либо туда передать либо сюда стащить

я поддерживаю (1) и (2) невзирая на чёс ДропБокса

оно бьет файл на чанки, считает хеши от чанков и сравнивает с хешами на сервере.

(7) Выгрузи в дропбокс конфу, потом поменяй что-то в конфе, потом выгрузи в файл в дропбоксе ещё раз. Как показывает мой опыт сидения на ADSL, вторая синхронизация будет НАМНОГО быстрей первой.

(6) Ага, хеши и чексумы придумали мёртвые люди из толстых пыльных книжек чисто для диссеров.

(8) Именно, но кому какое дело до "чёса"?

(6) Дык можно разбить на блоки, допустим, по 16 кБ, и посчитать для них контрольную сумму. Размер контрольной суммы - по желанию. Можно по 2 байта на блок, можно по 4, 8, 16. Передаются контрольные суммы, вот они-то и сравниваются.

(12) Если в начале файла добавить пробел - оно поймёт, что блок сдвинут и надо передать только первый?

(13) спасибо, хоть один поддержал, а то накинулись типа я не знаю про контр. суммы и прочую хню

(13) А почему бы и нет, можно же и diff файла сделать на клиенте, а не тупо контрольные суммы считать.

Узбагойся, никто тебя не поддерживал. Шутка.

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

(15) Мне и самому интересно, просто руки не дошли до использования дропбокса или аналогов, по старинке ношу флешку.

(15) "diff файла сделать на клиенте"

diff с чем делать будем?

http://en.wikipedia.org/wiki/Rolling_hash - знакомьтесь, 1с-ники, математика!

(16) я не отрицал опимизацию и прочее, а вот с хэшами, как повезет, а то не оптимизация а наоборот пролет может выйти

(13) Дык если ты в начало файла добавишь пробел - то у тебя и локально весь файл перепишется. Т.е., формально у тебя изменятся ВСЕ блоки.

(18) Дык на клиенте можно и предыдущую версию хранить, если уж на то пошло...

(22) какой размер ДропБокса счас?

придется же пред. версию всего что там есть хранить

(5) И как же они это делают?
Что б достоверно сверить два файла, нужно иметь на одной стороне оба варианта файла. Т.е. либо нужно с сервера загрузить файл имеющийся на сервере и сравнить побайтно с версией готовящейся к передаче, либо передать файл на сервер и там сравнить.
Сравнение по Хэш может иметь коллизии. Я бы не стал доверять системе выполняющей сравнение файлов по хэш суммам.

(25) мне вопрос???
это либо дропу вопрос, либо к тем кто мне тут понаписал что я неуч и нифига не шарю в хэшах :)

(25) rsync проверенное более чем десятилетием решение , тоже использует хэши блоков , технология более чем обкатанная , можно спокойно доверится.

(25) кстати, если [либо передать файл на сервер и там сравнить]? ИМХО, в таком случае сравнение теряет всякий смысл

(24) Э-э-э... зачем всего? Только того, с чем работаешь в последнее время. Все остальное довольно быстро устареет, если работать с разных девайсов...

(29) а если ты офф лайн так сказать будешь менять что то?

(30) Фиг тебе, а не оффлайн. Ведь прежде чем менять локальный файл - надо убедиться, что это последняя версия.

т.е. если я не подключен, я не поменяю все что захочу локально?

или как понять фиг мне?

WebDAV штука неплохая в своей идее, но реализации убоги без исключений..

не совершенства в этом мире :)

(32) Даже если ты сможешь поменять - то не факт что потом не возникнет коллизий при синхронизации. Так что не стоит этого делать, если не уверен в 100% одинаковости файла локально и на сервере.

(36) ))) очень удобная система)))

(36) и нахрена геммориться с хэшами, когда других более важных проблем куча

(37) "Не нравится - не ешь."(с)

(39) спс, я и не ем

Ветка отдает мракобесием. И практику уже привёл, и теорию, ан нет - "корабли без парусов - это нелепость".

(41) ответь на (18), если не затруднит

(42) diff не делается, математика для файла с измененным размером в (19). И кроме того - есть ПРАКТИКА в (9) - проверь сам.

(37) Дык а как ты хотел? Как еще можно обеспечить целостность файла при многопользовательской работе? Тем более что далеко не все программисты открывают файл с правильным режимом разделения доступа...

(44) Вообще-то конфликты нормально разрешаются, если будут конфликтующие версии файла - сохранятся обе.

(43) насчет практики
отправка через квип файла размером несколько килобайт занимает от полуминуты до нескольких минут, вопрос - что за фигня? многократная передача одного и того же просто время потянуть?

(46) Я понятия не имею, что у вас там в квипе, и при чем он тут.

(45) Дык а какая будет открываться при доступе к файлу?

(43) насчет "diff не делается":
а как же твое же (15) понимать?

(48) так глубоко лучше не зарываться, думается, прислушиваясь к твоему же (36) "Так что не стоит этого делать, если не уверен в 100% одинаковости файла локально и на сервере"

(49) >а как же твое же (15) понимать?
Как гипотезу при недостатке информации. Гипотеза не подтвердилась гуглением.

(47) к тому что ваша практика не показатель

(51) т.е. только сегодня узнал про CRC? благодаря гуглу?

(48) Одна из двух, какая именно - спроси у дропбокса. Вторая
(53) Мля... Про CRC я узнал лет 15 назад. Вопрос - когда ты про него узнал. И главное - почему ты путаешь проверку целостности и хэширование потока.

(54) "Вопрос - когда ты про него узнал", примерно так же как и ты

>Одна из двух, какая именно - спроси у дропбокса. Вторая
*Вторая хранится в папке cо словом Conflicts в названии. Сталкивался пару раз. Неудобство в том, что объединять приходилось руками.

(55) Ну так может прочитаешь и подумаешь, чем Кольцевое хэширование отличается от CRC.

(57) CRC - это общее выражение, а не принцип выделения его, суть в том что ни один ХЭШ не в состоянии гарантировать стопроцентную целостность или восстановление потерянных моментов

(8) разбиение на чанки работало до тех, пока систему обмена Dropbox-а не похакали и им пришлось вводить жёсткое шифрование, которое поломало обмен с дроблением на куски. Правда это было уже давно и они могли придумать как и шифрование сделать и чанки сравнивать.

(58) Видимо дураки авторы rsync-а этого не знают, господин теоретик.

(60) видимо знают

(59) Оно до сих пор работает. Не работает дедупликация - т.е. совпадающие блоки ищутся только в том же файле сейчас, а не во всех файлах.
(61) Знают, и всё равно сделали систему синхронизации на хэшах?

(62) а есть другие варианты?

(64) Вы еврей?

походу да :)

*(64)->(63)

(66) а почему как еврей так сразу на Вы перешел? :)

(67) Точно еврей. Альтернатива - тащить весь файл, но почему-то этого не делают.

(0)Только блоки.
Это собственно его основная фишка, отличающая его от многих других облачных сервисов синхронизации.

(68) я просто не пойму нафига с таким пафосом открывать Америку про контрольные суммы? наверное даже ребенок знает что любой пакет в сети(и не только) считается принятым только тогда когда контр. сумма на приемной стороне совпадет

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

знаю что есть... давно знаю

(70) Проверка целостности(идентичности) блока/файла и проверка "что и где именно изменилось" - разные задачи, если что.

(25)-"Сравнение по Хэш может иметь коллизии. Я бы не стал доверять системе выполняющей сравнение файлов по хэш суммам."

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

(71) в чем же разница? объясни
проверить пакет/кусок файла/весь файл, на мой взгляд разницы нету

(72) "Ну и окончательно - когда блок загружен можно уже побайтно сравнить и окончательно увериться в отсутствии коллизий."

сведет на ноль всю пользу предыдущих проверок

(73) Пример различия приведен в (13). Задача нахождения места изменения - сложнее, чем задача нахождения факта изменения. Средства - похожие(но не идентичные), но для нахождения факта можно посчитать md5, а для всех блоков md5 считать - опупеешь.

(58)Хэш собственно и не должен что то гарантировать, и тем более восстанавливать.
Хэш служит лишь для быстрого сравнения - если хэши разные, то данные однозначно разные.
Если хэш совпал, значит либо файлы одинаковые либо коллизия.
Проводится дополнительная проверка чтобы исключить коллизию.

(76) "Проводится дополнительная проверка чтобы исключить коллизию."

как именно?

польза только одна - хэш совпал - считается что все правильно передано или что объекты равны

(74)С чего бы это?
Суть системы обеспечить минимальный трафик между хостами.
Суть проверки - не допустить передачи того блока который уже есть на другом хосте.
Двойная передача одного блока случается только в случае коллизии. Но поскольку это случается крайне редко, то система свою задачу выполняет.

(78) ты сам написал - первый контроль прошел проводим еще один, опять прошел, сравниваем весь переданный блок побайтно, прочитай внимательно всё в своем (72)

(77) facepalm.jpg
Берешь две разные функции, считаешь два разных хэша. Вероятность коллизии для двух посчитанных хэшей равна произведению вероятностей.

(80) прочитай тоже внимательно всё в (72) Jump -а

Чувствую, сейчас докатимся до дискуссии "Уникален ли GUID? Я очень боюсь, что у меня два совпадут!".

(77)Смотри - на хосте А есть блок нужно проверить стоит ли его передавать на хост Б.
Считаем хэш этого блока - если его хэша нет в БД хоста Б то однозачно передаем этот блок.
Если хэш нашелся в БД хоста Б то тут ситуация сложнее - либо это коллизия, либо такой файл есть, проверяем его более сложной хэш функцией на обоих хостах и по результату делаем вывод.

(81)Ну насчет побайтного сравнения я лоханулся. Это немножко не из той оперы.
А в остальном все верно.

(84) тады ква :)

(83) Это не исключает ошибку, лишь минимизирует её. Штука в том, что такой надёжности достаточно для повседневного применения. С тем же(если не большим) порядком малости может накрыться локальный носитель или умереть сам хозяин информации :)

Побайтное сравнение применяется не в дропбоксе и аналогах, а в дедупликации, когда файлы на одном диске и передавать никуда не надо.
Там да, при совпадении хэша на всякий пожарный проводится побайтное сравнение.

(82) я не понял зачем было открывать Америко/Вики про хэши? про них знают даже дети

(87) а смысл?
получается:
не совпал - передаем всё
совпал всё равно передаем всё что бы убедиться

так что ли? смысл проверки тогда

(88) Я привёл ссылку конкретно на кольцевой хэш. Я забыл о его существовании, и нагуглил именно то, что он применяется в дропбоксе.

(88) Заело что ли?

(86)Да минимизирует. Но там такие порядки, что не стоит даже заморачиваться. Т.е есть вероятность что луна на голову свалится, и она ненулевая.

(91) как и оппонента

(89)
Не совпал - передаем.
Совпал - хэшируем другим алгоритмом, более сложным и долгим, но имеющий на много порядков меньшую возможность образования коллизий, и передаем ХЭШи а не файлы для сравнения.

(89) Нет, если совпал 1,2..n раз - не передаём блок вообще. Чем больше n - тем больше надёжность.

(95) что нет? читай в (87)

"Там да, при совпадении хэша на всякий пожарный проводится побайтное сравнение."

что есть "побайтное сравнение"?

(96) Тебя заело? Jump уже сказал, что лоханулся с побайтным сравнением.

(97) в (84) написал лоханулся, а (87) опять тоже самое

(94) (95) В принципе, да. Подобная схема сведет вероятность коллизий практически к нулю.

(98) Ты прав в том, что емли мы априори хэшам не доверяем - то считать - смысла нет, всё равно потом побайтно сравнивать.

(100) так и я про тоже. есть проверенные алгоритмы, и нет смысла проверять ими. а при совпадении проверять сложнее, сложнее и в конце концов сравнивать побитно, типа "не может быть что всё правильно"

только если не совпало

(101) Вообще не доверять проверке целостности - нонсенс :) Она же везде. Ты же не закладываешься на то, что тебе корректные TCP-пакеты с мусором попадут, или с диска мусор считается, хотя контрольная сумма совпадёт.

(102) я где то отрицал это?

(98)Прочитай внимательнее (87)там не тоже самое :)
я там лишь объяснил почему лоханулся.
В дропбоксе побайтное сравнение исключено, т.к файлы в разных местах.
В дедупликации локальной оно применяется т.к файлы в одном месте и проще сравнить побайтно, чем считать сложный хэш.

(103) В (57) например. Коллизии, коллизии, кругом одни коллизии.

Тьфу, в (58).

(104) не буду биться об заклад но думаю кнтроллер винта в конце пакета передает контр. сумму, так что даже если сравнивать два файла на одном винте все равно будет использоваться принцип "проверили КС, не совпало проверяем точнее"

(106) в (58) дословно сказано 100% гарантии нету.. и не больше, там я не говорил что не доверяю КСам

(108) 100% гарантии сохранности чего бы то ни было нет ни в каком случае.

+(109) И хэши тут качественно ничем не выделяются.

(109) так на что (106) тогда указывает? :)

(107)Примерно так оно и есть.

(111) На то, что ты подчеркнул отсутствие 100% гарантий как качественную особенность хэшей.

(113),(111) Хорош спорить о том, кто, где, что не так сказал.

С сабжем вроде разобрались?

(113) ты с этим поспоришь, а говоря что нет 100%, я не имел ввиду что я не доверяю... мне и 70% хватит

(114) с сабжем только после декомпиляции и анализа продукта :)

а мы пока про возможность того что это так и есть в ДБ:)

(114) Мне и разбираться не надо было, я и так знал про частичную синхронизацию и регулярно ей пользуюсь :)

(117) а вот команда ДБ пишет почему то для "опытных пользователей" что "Перед передачей файла мы сравниваем его последнюю и предыдущую версии", тут вроде ничего про хэши нету... или я не вижу

(116)Ну декомпиляция не обязательна.
Можно просто провести тестирование на специально измененных файлах.
Я этим кстати баловался.
Как в случае с дропбоксом, так и в случае с дедупликацией от майкрософта.

(118)Ну ты не совсем правильно их понял.
В дропбоксе помимо всего прочего есть еще и хранение версий.
Т.е можно откатиться к версии файла которая была вчера, или неделю назад.

(118) Во-первых, тут ничего нет и про средства сравнения. Вообще. И как оно делается - сравнением хэшей, или по-другому - не указано. Или "сравниваем" это именно "сравниваем побитово"? А во-вторых, там написано "для опытных пользователей" а не "для программистов и хакеров".

+(121) А две версии - это клиентская и серверная.

(120) Имеет место, но к сабжу не имеет прямого отношения.

(121) не спорю:) ибо думается "для опытных пользователей" = "могут установить винду":)

(117) а вот так было бы грамотно сказано из (117):
"используется частичная синхронизация"

(125) к (121)

(13)Кстати да. Хитрый вопрос.
Но тем не менее поймет.

Вот тут есть вроде неплохая статья о dropbox.
http://habrahabr.ru/post/163189/
Файлы бьются на блоки, и да, передаются измененные блоки. Только некоторые файлы могут содержать всего один блок. И при изменении они будут передаваться полностью. Такие файлы скорее всего будут иметь размер до 4 мб.