jim945 |
|
Темы:
9
Сообщения:
3194
Участник с: 25 января 2010
|
vasekКаким боком rsync тут? meld удобен наглядным сравнением схожих каталогов и файлов. В контексте причём.
Lupus pilum mutat, non mentem.
|
AZJIO |
|
Темы:
51
Сообщения:
605
Участник с: 05 января 2021
|
Из лучшего на винде "Beyond Compare 3", но платная, сравнивает и бинарные при чём не сбивается в абсурд на первом несовпадениии, а умеет вычленять блоки, и изначально у ней удобная подсветка, практически из коробки работает на ура и сравнение фото показывает маску разности. Больше всего конечно движок поиска в проге, а уж гуи для презентации, уже дальше только придумывать куда его воткнуть, например у меня для винды есть проги синхронизации, прога поиск файлов по списку, переименование, поиск дубликатов... в них одна и та же библиотека поиска файлов. И кстати я пробовал у меня и под линуксом на Wine запустилось и выдал список и сортировка работает и формирование списка. vasek поиск в бинарникахдля винды у меня тоже работает и для бинарников (и под wine) jim945 Поэтому я и пытался добиться примеров использования.надо учесть что когда то я активно занимался одними вещами, теперь другими, многое из того что я сделал не пользуюсь. Но буквально вчера мне пишут "дай исходник". И скачивание файлов пока продолжается. |
nafanja |
|
Темы:
94
Сообщения:
9252
Участник с: 02 июня 2012
заблокирован
|
vasek мы ж говорили о очень специализированном ПО.а тут мы видим acl, разные архиваторы (компрессоры!!!), хеши, даже перл...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874 |
vasek |
|
Темы:
47
Сообщения:
11881
Участник с: 17 февраля 2013
|
jim945rsync используется для инкрементального бэкапа и эта утилита все знает - какие файлы изменились, какие файлы добавились, какие файлы исчезли - и имеет кучу опций, используя которые можно получить нужный вывод. Кроме того, эта утилита имеет хорошее/лучшее быстродействие. А что конретно использовать, каждый решает сам.
Ошибки не исчезают с опытом - они просто умнеют
|
vasek |
|
Темы:
47
Сообщения:
11881
Участник с: 17 февраля 2013
|
AZJIOДля бинарников одной утилитой, как правило, не обойдешься - намного удобнее использовать две - одна находит только совпадение, другой смотришь
Ошибки не исчезают с опытом - они просто умнеют
|
AZJIO |
|
Темы:
51
Сообщения:
605
Участник с: 05 января 2021
|
vasek Концепция AutoIt3, на которой написана прога - воспринимать любые данные как строку, это у других языков null - конец строки (не у всех, у |
vasek |
|
Темы:
47
Сообщения:
11881
Участник с: 17 февраля 2013
|
AZJIOЗдесь большое значение имеет время, которое необходимо утилите для просмотра тысяч файлов, не нагружая при этом cpu.
Ошибки не исчезают с опытом - они просто умнеют
|
AZJIO |
|
Темы:
51
Сообщения:
605
Участник с: 05 января 2021
|
vasek Некоторые вещи зависят от языка. Я думаю обращение к файлам происходит вызовом системных функций, потому что они одинаковы, открывают дескриптор поиска и начинают запрашивать следующий файл, перемещая указатель в поисковом дескрипторе. Но конечно зависит оптимизация алгоритма. Например в архиве есть "старая версия" - работает быстрее, потому что она только выводит данные в строку, а метод копирования максимально снижен по расходам - даётся указатель на строку и данные копируются в памяти по указателю. Новый код там генерируются переменные, а это внутреннее обслуживание переменной, выделение/перевыделение памяти, что тормозит выполнение, а с учётом разрезания/склеивания элементов формируя заданный вывод, конечно несёт в себе расходы. И ранее в AutoIt3 аналогичной проге я делал метод вывода списком и обрабатывал его одним регулярным выражением за один проход, этим я снизил скорость с 10 минут до 4 минут при обсчёте целого диска. Измерение проводится после первого запроса, потому что данные кешируются и первый запрос всегда работает медленнее, так как заново пишет кеш, а второй тест определяет уже скорость именно работы алгоритма, т.е. скорость доступа жёсткого диска уже практически не влияет на результат, так как выдаёт один и тот же показатель. В PureBasic как и в других языках нормально получать дескриптор на скомпилированное регулярное выражение, поэтому я могу использовать его повторно не тратя время на компиляцию, но думаю всё равно за один проход будет быстрее. Так что я пока не тестировал такой вариант, это уже подгоняется под прогу, если нужно выдать данные в конце, или же выдавать данные в процессе... Ещё момент, например FSearch и Everything при запуске создают базу данных файловой системы, и работать с уже полученным списком гораздо быстрее чем каждый раз его запрашивать у жёсткого диска. |
vasek |
|
Темы:
47
Сообщения:
11881
Участник с: 17 февраля 2013
|
Все это теория, я практик ... как пример, директория /usr/lib содержит около 95 тыс. файлов. Найдем файлы, которые содержат выражение corruption detected ноутбук слабенький, HDD ... затрачено около 6 мин и выявлено 13 файлов PS - последующие поиски других сочетаний в той же директории идут намного быстрее, около 10-20с Проверяем, выборочно, то ли найдено strings /usr/lib/modules/5.10.16-arch1-1/build/vmlinux | grep 'corruption detected'
Ошибки не исчезают с опытом - они просто умнеют
|
AZJIO |
|
Темы:
51
Сообщения:
605
Участник с: 05 января 2021
|
vasek Сделал, если сортировку не использовать то у меня 37 000 файлов за 250 мсек, то есть мгновенно. Если в вывод добавить дату то, 420мсек, ещё и с размером 530мсек. |