LINUX.ORG.RU
ФорумAdmin

Потрясающий косяк в UNISON

 , ,


0

2

Найденный потрясающий косяк в UNISON - это мое безапелляционное мнение. Хотя готов выслушать мнение других знатоков, прежде чем писать злобное иссуе его создателям, или же сборщикам, это будет зависеть от вас. Злобное - потому что не ожидая подвоха, засинхронизировал тысячи документов между двумя компами.
Раз, другой... как вдруг заметил, что даты и время документов поменялись!!!

Для меня это событие сродни настоящей IT-катастрофе, поскольку ДАТА и ВРЕМЯ для меня играет важнейшую роль (достаточно вспомнить TheirBirthday).
Они позволяют мне ориентироваться в тысячах документов, понимая, когда они были мною созданы или модифицированы и принимать соответствующие решения.
Может, для кого-то это и не важно, но для меня чрезвычайно критично для работы с ними.
В итоге пришлось доставать документы из бекапов, сравнивать, анализировать и восстанавливать, на что ушла уймища времени, вот поэтому сейчас я очень зол.

Итак, с преамбулой закончено, перехожу к сути.
Да, я в курсе, что UNISON создан не Васяном на коленках, а неким профессором, поэтому можно надеяться, что продукт достойный, достаточно вспомнить профессора Никлауса Вирта и его Pascal. Однако, как часто это бывает, дьявол кроется в мелочах.
В данном случае UNISON при репликации с какого-то, извините, хера, меняет оригинальную ДАТУ и ВРЕМЯ на момент репликации! Это звездец...

По моему стойкому убеждению, ДАТУ и ВРЕМЯ документов и файлов имеют право менять только те приложения, которые с ними непосредственно работают, т.е. их создают, редактируют и т.п.
За примером далеко ходить не надо - достаточно взглянуть на MC, который создали умные люди: при копировании в нем галочка "Сохранять атрибуты" по умолчанию взведена.
Взведена, а не сброшена, как в UNISON!

Поэтому при копировании или синхронизации ДАТА и ВРЕМЯ НЕ ДОЛЖНЫ меняться!!! (кроме особых случаев, определяемых нами, пользователями)
Иначе наступит временной хаос, как и случилось у меня. Из-за того, что UNISON, которым я пользуюсь в Manjaro ARM, ведет себя ровно наоборот.

Конечно, позже я отыскал ключик times и захерачил его в конфиг default.prf в виде -

times = true
и его благотворное действие глобально распространилось на все существующие и создаваемые профили.

Казалось, можно было бы успокоиться? Ну уж нет!
Идиотское дефолтовое поведение UNISON настолько потрепало мне нервы и сожрало драгоценное время, что у меня руки чешутся ткнуть, как котенка, проффесора или сборщика, мордой в этот алгоритмический косяк, вопрос только - кого?

Итак, что вы об этом всем думаете? И как ведет себя UNISON в ваших дистрибутивах, отличных от Manjaro?
Это и поможет выявить, кого надо ткнуть.




Перемещено hobbit из general

★★★★★
Ответ на: комментарий от CrX

А алиасов у меня полно, естественно. Не использовать их — глупо

Значит, тебе повезло 😊 Само понятие «алиас» по замыслу для меня с самого начала казалось каким-то неполноценным, обманом, фальшивкой, поэтому так и не привык к нему и не пользуюсь.

В-общем, наши представления о мироустройстве коренным образом разошлись как море корабли 😜
Отсюда еще раз вопрос - есть ли на ЛОРе возможность для юзеров создавать голосования?
Уж очень хочется узнать, что думают об отображения времени файлов другие люди.


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

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 3)
Ответ на: комментарий от chukcha

Отсюда еще раз вопрос - есть ли на ЛОРе возможность для юзеров создавать голосования?

Конечно есть. Но не факт, что подтвердят.

в неподтверждённых — кнопочка добавить

Уж очень хочется узнать, что думают об отображения времени файлов другие люди.

Да и так очевидно, что ты скорее всего такой один. Вероятно ещё парочка троллей присоединится.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от chukcha

Правильный просмотр должен быть по умолчанию.

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

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

shell-script ★★★★★
()
Ответ на: комментарий от chukcha

Но такое не может быть! Rsync ведь не ведет свою базу данных!
Полученные результаты ни в какие ворота не влезут и ни на какой глобус не налезут.

А в чем проблема-то ? Основное время один фиг занимает само копирование, а есть там база, нет базы… монопенисуально. Пожалуй исключением, когда rsync сильно просядет, будет вариант его запуска только в единственном экземпляре ( не клиент-сервер) с ключиком подсчета контрольной суммы для сравнения файликов.

anc ★★★★★
()
Ответ на: комментарий от anc

На самом деле никакую. Оно новые файлы создаёт с собственно текущей датой. Но в терминах ТС это «меняет», и он хочет чтобы копировало с оригинального файла (как у cp --preserve=... и rsync -a). Причём такая возможность есть (как и у cp и rsync), но он считает, что так должно быть по умолчанию. Причём для всех, потому что конкретно ему для его юзкейса так надо…

CrX ★★★★★
()
Ответ на: комментарий от anc

А в чем проблема-то ? Основное время один фиг занимает само копирование, а есть там база, нет базы… монопенисуально.

Не так. Если вы наблюдали копирование с помощью Rsync большого числа файлов, то видели бы, что сначала он вообще не копирует,
а только сверяется с файлами в источнике и таргете, и лишь потом приступает к копированию.
И если файлов много, то сверка тоже занимает много времени.

Особенно эта разница наблюдается, когда файлов много и мелких.

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

У тебя там меньше двух тысяч файлов, какая там сверка, которая бы занимала много времени? Я понимаю, их бы миллионы, ну хотя бы сотни тысяч были.\

А ещё для полноценного тестирования, надо sync делать файловые кэши чистить. У тебя вся эта структура в памяти сейчас по сути.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

У тебя там меньше двух тысяч файлов,

Это был тест на десктопе с двумя тысячами. А на реальном дедике их сотни тысяч, если не миллионы, Если не забуду, посчитаю.
Выше уже сообщал, что недавнее рсынканье с него длилось ~100 минут.

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от CrX

Да уже сомневаюсь, что она уж будет такая ощутимая.
Тем более, что по использованию UNISON на десктопе, заметил, что он штука капризная из-за этих баз.
Так что скорее всего буду продолжать пользоваться Rsync и Rsnapshot

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

значит, в других местах односторонняя?

И что? Если она хотя бы в одном месте двусторонняя, то это уже основание для использования Unison. Чтобы везде было одинаково.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от CrX

Юзал Unison для репликации файлов на резервный сервер. Файлов было порядка 30000, и, субъективно, было очень медленно. Просто очень медленно, казалось, что rsync сделал бы все быстрее.

Выгода может быть только если прикрутить inotify для обновления базы. В Unison вроде как есть нативная поддерка inotify.

bigbit ★★★★★
()
Последнее исправление: bigbit (всего исправлений: 1)
Ответ на: комментарий от chukcha

Так ты хочешь сказать, что первичное создание файла, например, редактором, и перекладывание уже созданного файла в другое место должно давать одну и ту же дату/время?

Ну во всяком случае хотелось бы.

Интересно, можно ли на нашем форуме провести голосование по данному вопросу?

Почему нет?

anc ★★★★★
()
Ответ на: комментарий от chukcha

Правильный просмотр должен быть по умолчанию.

Понятие «правильный» у каждого своё. Одному например правильный «фиолетовый», другому «сыпучий», третьему «мокрый»…

anc ★★★★★
()
Ответ на: комментарий от anc

Так ты хочешь сказать, что первичное создание файла, например, редактором, и перекладывание уже созданного файла в другое место должно давать одну и ту же дату/время?

Ну во всяком случае хотелось бы.

Видимо, я как-то неправильно сформулировал этот вопрос, так что сам запутался :-)
А как его поняли вы?

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от anc

Не «ибо нефиг», а ибо нафиг ненужно.

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

CrX ★★★★★
()
Ответ на: комментарий от anc

Я точно не предлагаю, говорю же нефиг. Но какие-нибудь упоротые могут.

В tar же, например, именно имя, и на этом многие палятся, как я выше писал.

CrX ★★★★★
()
Ответ на: комментарий от CrX

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

Да, пускай и не ахти какая приватная информация, но всё же имя юзера и группы, время, когда был сохранён файл и по сути umask
— дополнительная инфа о юзере, которую тот передавать не планировал.

Хм, усиленно заботясь об анонимности этой дополнительной информации о файле, как-то подзабыли о более важном - самой информации, которая содержится с самом файле, и которая по сравнению с дополнительной просто семечки. В смысле наоборот 😜

chukcha ★★★★★
() автор топика
Ответ на: комментарий от chukcha

Уточняем:

В файловой системе ext4 для каждого файла хранятся следующие временные параметры:

- mtime (modification time) - время последнего изменения содержимого файла
. ctime (change time) - время последнего изменения метаданных файла (например, прав доступа или владельца)
. atime (access time) - время последнего доступа к файлу
. crtime (creation time) - время создания файла. Это новый параметр, добавленный в ext4 по сравнению с ext3


Итак, какое время их этих мы видим видим по команде ls -l или в MC?


Upd. Крайне удивлен - а что, действительно ext3 не было времени создания файла?? 😲

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 2)
Ответ на: комментарий от chukcha

как-то подзабыли о более важном - самой информации, которая содержится с самом файле, и которая по сравнению с дополнительной просто семечки

Почему сразу подзабыли? Разве с её передачей есть какие-то проблемы, о которых надо отдельно упоминать? Вроде с этим всё нормально и обсуждать (по крайней мере в рамках этой темы) особо нечего.

CrX ★★★★★
()
Ответ на: комментарий от chukcha

Итак, какое время их этих мы видим видим по команде ls -l или в MC?

В ls по умолчанию mtime, естественно. Но можно изменить ключом --time= (или короткими -c и -u для двух других; для crtime вроде нет, можешь man ls сам).

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

В ls по умолчанию mtime, естественно.

Ага! Вот ты и попался 😂

- mtime (modification time) - время последнего изменения содержимого файла

Если это так, то при копировании, т.е. при перекладывании файла с места на место, это время не должно меняться.

А оно в UNISON по умолчанию меняется, и это большая глюпость.
Да и не только в нем ...

chukcha ★★★★★
() автор топика
Последнее исправление: chukcha (всего исправлений: 1)
Ответ на: комментарий от CrX

Должно оно меняться, как и ctime. Потому что это новый файл, и время его модификации совпадает с временем создания.

Я вот что-то не могу сформировать чёткое мнение по этому вопросу. Ведь unison - это система синхронизации директорий. Поэтому кажется логичным, что после того, как синхронизация произведена, директории должны быть идентичными. А у нас получается, что содержимое файлов идентично, а время модификации - не совпадает.

Мне это неважно, потому что всё равно все проекты в git, но в целом точка зрения тов. чукчи понятна.

Beewek ★★
()
Ответ на: комментарий от Beewek

Синхронизация — это про содержимое. Владелец может быть разный, даже пермиссии, а по времени создания/изменения вообще может быть очень полезно смотреть как раз когда какой файл был именно синхронизован.

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

Но по умолчанию должно быть именно ожидаемое поведение: новый файл — новое время создания и изменения. Обычный юзер ожидает этого. Не только исходя из того, что это всё же именно два разных файла, хоть и с одинаковым содержимым, но ещё и хотя бы даже из-за того, что привычные утилиты, которые делают то же самое (rsync и совсем уж стандартный cp) делают так же. Более стандартное/привычное поведение по умолчанию — это всегда плюс. А возможность изменить его под свои потребности или своё видение, «как оно должно» — ещё больший плюс.

CrX ★★★★★
()
Ответ на: комментарий от MoldAndLimeHoney

Забавно, что Syncthing, который написан на языке «для тупых» каким-то чуваком просто работает.

Забавно, что регистрант не способен даже элементарную инфу найти в этом вашем интернете.

https://github.com/syncthing/syncthing/issues?q=is%3Aopen+is%3Aissue+label%3Abug

В «просто работающем» Syncthing багов хватает, это не говоря об проблемах безопасности «из коробки». Видать программирование на языке для тупых сказывается))

PRN
()
Последнее исправление: PRN (всего исправлений: 1)