https://www.opennet.me/openforum/vsluhforumID3/102491.html Представлен новый выпуск rmlint 2.2.0 (https://github.com/sahib/rmlint), утилиты для чистки файловой системы, выявляющей дубликаты файлов и директорий, исполняемые файлы с отладочной информацией, повреждённые символические ссылки, пустые файлы, файлы с некорректными идентификаторами владельца и группы. Кроме штатного режима сравнения по контрольным суммам, доступен режим побайтового сопоставления. Программа отличается высокой производительностью, поддержкой различных форматов вывода (отчёт в JSON, shell-сценарий чистки), возможностью проверки только новых файлов. Код написан на языке Си и распространяется под лицензией GPLv3.<br><br><br><br>URL: http://www.reddit.com/r/linux/comments/35g1hy/rmlint_220_released_fast_duplicate_finder/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=42200<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#52 Tue, 12 May 2015 06:09:52 GMT Луче перефразировать более корректно: Быстро написать для себя - хорошо, но быстро написать тормозное, тяжелое и непортируемое по для других - это зло.<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#51 Tue, 12 May 2015 06:08:20 GMT В случае питона с возрастом растет его размер, тормознутость и жручесть оперативки. И работа по улучшению в этих направлениях не ведется, поскольку они не являются задачами данного языка.<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#49 Mon, 11 May 2015 22:45:14 GMT А как же явный пример между С++ и --E ??? Через десяток лет и --Е станет крутым. Возраст - важный аспект для оттестирования всего вся в языке.<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#48 Mon, 11 May 2015 19:44:46 GMT &gt;&gt; Ищет дубликаты файлов и позволяет их между собой захардлинкать, полезно для бэкапов <br>&gt; Особенно когда под файлом вылезет бэд.<br><br>Хламовник бэкапнику не замена.<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#47 Mon, 11 May 2015 19:43:46 GMT &gt; .. и именно поэтому не рекомендуется писать код на <br>&gt; bash размером более чем три короткие строчки :-) <br><br>Это если четыре штанины. А так-то http://docs.altlinux.org/archive/2.2/master/devel-html/ch03.html#id2816285<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#46 Mon, 11 May 2015 19:36:12 GMT &gt; Вот только недавно искал нечто подобное.<br><br>Их довольно много, сходу вспомнилось findd.<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#45 Mon, 11 May 2015 15:45:59 GMT &gt; Hint: в именах файлов может быть "*", "?", " ", и другие веселые символы. Что очень доставляет при попытке автоматизировать обработку.<br><br>hint: такая проблема есть только у bash (и ну ни как не у Python) .. и именно поэтому не рекомендуется писать код на bash размером более чем три короткие строчки :-)<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#44 Mon, 11 May 2015 13:45:37 GMT возможно ошибаюсь, но вроде где-то читал,<br>что fdupes сначала по размерам сравнивает, потом(если размеры совпали) по crc, а потом по md5 или sha<br> https://www.opennet.me/openforum/vsluhforumID3/102491.html#43 Mon, 11 May 2015 13:27:23 GMT rmlint намного быстрее. fdupes сравнивает по контрольным суммам, но побайтовый режим часто быстрее. Например, если нужно сравнить два файла по 4Gb и они отличаются в первом байте, то побайтовое сравнение считает с диска только первый блок из каждого файла, а сравнение по контрольным суммам прочитает оба файла полностью. А из-за кеширования в Linux как правило файлы много раз считывать заново не придется, поэтому преимущество от контрольных сумм теряется. Но быстрее всех rdfind, там еще хитрые оптимизации с сортировкой файлов по inode.<br>