jdupes 1.28.0

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

А я только позавчера узнал, что автор удалился с Гитхаба.

У него ещё есть https://codeberg.org/jbruchon/imagepile.

a disk image block-level de-duplication tool

imagepile solves the problem of massively duplicated data between raw disk images. When you add an image to the «image pile,» this program checks them block-by-block against all of the blocks previously stored there, including previous blocks from the same image. If the blocks are identical, no new data is stored in the pile to store that block. This can result in staggering disk space savings because the only data that can expand the image pile database is unique data, and many disk images tend to have large amounts of repeated blocks throughout.

Прикольно. Но у меня нет юзкейсов для этого.

название подозрительное, исходники кто-нибудь смотрел?

А что подозрительного, что его зовут Jody?

Чем оно лучше fdupes?

$ diff jdupes.1 fdupes.1

Что-то он там на голубя много навалил, странный тип, проверяйте исходники

И что, оно чем-то лучше duperemove?

Не знаю. Я впервые слышу о duperemove.

Знаю только, что jdules быстрее и фичастее, чем ddupes, а тот в свою очередь вичастее, чем fdupes, о котором я узнал первым.

Но сейчас вот глянул, duperemove требует зачем-то sqlite3, а у jdupes минимум зависимостей. Хотя бы этим лучше.

upd: а ещё duperemove не умеет в хардлинки… То есть, вообще не то.

Не знаю. Я впервые слышу о duperemove. И, видимо, не я один, потому что его нет даже в AUR.

В Devuan/Debian есть.

Я успел исправить до ответа же…

Да, он и в арче есть, в репах, оказывается. Я просто перед этим искал по dupes, чтоб посмотреть, какие есть альтернативы, а надо было по dupe.

а ещё duperemove не умеет в хардлинки

Он умеет в рефлинки, которые намного полезнее.

Ты исправил после того как я открыл страницу :)

Он умеет в рефлинки, которые намного полезнее.

Ну, во-первых, зависит от юзкейса.

Во-вторых, для этого же необходима поддержка со стороны ФС? Какие ФС вообще умеют в рефлинки, и умеет ли в них ext4?

Ну, во-первых, зависит от юзкейса.

Ну мне сложно придумать реалистичный юзкейс, где нужны именно хардлинки. Могу придумать только случай, когда они будут не хуже: если все копии файла read only, то неважно, будут они заменены хардлинками или рефлинками. В противном случае, изменив одну из копий ты изменишь их все.

Во-вторых, для этого же необходима поддержка со стороны ФС?

Да.

Какие ФС вообще умеют в рефлинки, и умеет ли в них ext4?

Как минимум, xfs, btrfs, zfs, bcachefs. ext4 не нужна.

Ещё интересная https://github.com/jvirkki/dupd. Базу хранит в SQLite.
Есть старое сравнение с другими утилитами: https://www.virkki.com/jyri/articles/index.php/duplicate-finder-performance-2018-edition/

В противном случае, изменив одну из копий ты изменишь их все.

Ну вот с рефлинками не так, и в этом есть проблема. Хотя я прекрасно представляю юзкейсы, где как раз лучше, чтобы они «разъединялись» при редактировании.

Как минимум, xfs, btrfs, zfs, bcachefs. ext4 не нужна.

Ясно-понятно. Вопросов больше не имею, доказывать что-то не собираюсь.

Итого, ответ на изначальный вопрос: jdupes лучше тем, что умеет в хардлинки (в рефлинки, как я понимаю, тоже, если я правильно понял смысл ключа -B), в удаление совсем, не требует ФС из чётко обозначенного списка, не использует sqlite, имея самый минимум зависимостей. А уж кому что из этого важно, а что нет — это уже личное дело каждого.

Ещё интересная https://github.com/jvirkki/dupd. Базу хранит в SQLite.

Описание загадочное:

dupd enables an exploratory approach to finding duplicates in your
filesystems instead of only showing a static list of duplicate
files. See the docs directory for more information and examples.

Что конкретно оно делает, не подскажешь? В чём, собственно, заключается этот самый exploratory approach? А то в examples.md что-то многобукафф, и где собственно суть на примере отличий от того же сабжа и аналогов — непонятно.

Ну вот с рефлинками не так, и в этом есть проблема. Хотя я прекрасно представляю юзкейсы, где как раз лучше, чтобы они «разъединялись» при редактировании.

А вот мне интересно, где нужно именно поведение хардлинка, и причём в связи с автоматизированной дедупликацией.

Просто если мы заменяем копии на хардлинки, то мы N независимых объектов превращаем в один со счётчиком ссылок, которые при этом внешне выглядят как независимые. Т.е. если пользователи или программы не рассчитаны заранее на такой сценарий, то это с большой вероятностью приведёт к отстреленным ногам. А если рассчитаны, то каждый будет делать себе хардлинк в начале работы, и не понадобится дедупликатор.

Вот с симлинком всё предельно очевидно и для людей, и для программ.

Что конкретно оно делает, не подскажешь? В чём, собственно, заключается этот самый exploratory approach?

Я dupd очень давно пробовал. Попробовал повторить в dupd/tests:

$ dupd scan --path .
$ dupd report

56 total bytes used by duplicates of size 14:
  /home/dataman/Projects/C/---CLITools/FileDupFinders/dupd/tests/files2/path2/hello1
  /home/dataman/Projects/C/---CLITools/FileDupFinders/dupd/tests/files2/path1/hello1
  /home/dataman/Projects/C/---CLITools/FileDupFinders/dupd/tests/files/small1
  /home/dataman/Projects/C/---CLITools/FileDupFinders/dupd/tests/files/small1copy


86 total bytes used by duplicates of size 43:
  /home/dataman/Projects/C/---CLITools/FileDupFinders/dupd/tests/output.40
  /home/dataman/Projects/C/---CLITools/FileDupFinders/dupd/tests/output.58c

...очень много строк

$ dupd uniques – выводит список только уникальных файлов.
$ dupd dups – выводит список дубликатов.

И т. д. Наверное exploratory approach в этом – что сначала создается база, а потом уже можно делать разные штуки.

А вот мне интересно, где нужно именно поведение хардлинка, и причём в связи с автоматизированной дедупликацией.

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

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

которые при этом внешне выглядят как независимые.

это с большой вероятностью приведёт к отстреленным ногам

Да как бы ls показывает количество ссылок у файла, отличающиеся от 1 сразу видно, а vifm так вообще файлы с более чем одной ссылкой подсвечивает цветом.

Но так-то, конечно, человек всегда найдёт, как отстрелить себе ноги. Чтобы этого не происходило, надо просто понимать, что делаешь, и зачем.

Симлинки — это тоже хорошо и замечательно, но для другого.

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

Я сначала подумал с таким названием о дедупликации пикч (shameless plug) через хранимую базу

случаях за счёт хардлинков.

Где-то я слышал про какой-то сценарий при исполльзовании ссылок (толи hard, толи soft) и rsync ведущий к сбою. Когда админ делает копию, а копия не делается. Но так как hardlink только в рамках одной файловой системы, то скорее всего softlinks.

А так копии на диске дают уверенность, что если диск начнет сыпаться, то повышаеся шанс сохранения копии. Чего не дает hardlink.

По какому хэшу дубликаты ищет?

название подозрительное

Нашёл. :)
https://www.jdupes.com/2023/08/23/the-history-of-jdupes-why-its-called-that-and-where-it-came-from/

The short version The “J” stands for “Jody” and the name “jdupes” means “Jody’s fdupes.“ It was originally a set of patches by Jody Bruchon for fdupes that the fdupes guy rejected. Development continued, the project was renamed, and jdupes has long surpassed fdupes in both features and popularity.

Prehistoric times: fdupes is king
jdupes began as a simple modification to a duplicate file finding utility called fdupes (which literally stands for “find duplicates”) by Adrian Lopez. fdupes has been around since at least 1999 and has been the de facto duplicate finder tool for Linux and BSD systems ever since I can remember. I used fdupes for a long time and was relatively happy with it. If you weren’t using Windows or Mac OS in the 2000s and you needed to find duplicate files, you were using fdupes.

По какому хэшу дубликаты ищет?

xxHash64.

Более подробно: https://www.jdupes.com/2023/08/28/news-hash-database-feature-cross-copying-hard-link-hashes-jdupes-leaving-github/

Every time jdupes examines a pair of files to see if they could be duplicates, the contents of both files are read and hashes (numbers based on a file’s contents that are used as a “shortcut” to quickly compare that file against other files) of the contents are generated, then they are compared to see if files should be examined even further. An upcoming performance enhancement to jdupes is hash cross-copying. This is where two files being compared during a scan are found to be hard-linked (they look like two separate files to the user but point to the same data and metadata on-disk) and the hashes are copied between the in-memory information about each file. Before this enhancement, two files that are literally the same file would be hashed and compared separately, potentially wasting a lot of time re-reading the same data to calculate the same hashes. While this enhancement doesn’t completely avoid this unnecessary work, it does avoid it after a hard-linked pair of files is detected. This can result in a significant performance boost. It will be included in the next release of jdupes.

Ну, я могу сконструировать. Допустим, есть у тебя mirror.something.org, а на нем — срезы репозитория по датам, read-only, выкачиваемые тобой ежедневно. Если пройтись и наделать хардлинков, то rsync того, кто зеркалит тебя, потом будет знать, что достаточно файл передать один раз и тоже нахардлинкать. А с рефлинками так не выйдет.

Но это — синтетический пример.

picunic

О, на raygui! Необычно. :)

Давно не смотрел на AntiDupl (на C#); оказалось, что автор наконец-то написал консольную и кроссплатформенную AntiDuplX.

А я для этого баш-скрипт делал...

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

Ну мне сложно придумать реалистичный юзкейс, где нужны именно хардлинки.

Получил большую core. Сделал на нее симлинк, попросил не удалять файл, пока разбираюсь.

Файл снесли.

===

Получил большую core. Сделал на нее хардлинк.

Файл снесли. Мне пофиг, у меня остался.

:)

jdupes, написанной на языке C

внезапно

Я похожую утилиту для себя на питоне написал и активно использую. Хотелось бы ещё находить дубликаты в файловой системе и в архиве (.tar.gz какой-нибудь или ещё чего). Хочу это в свою утилиту добавить, да всё лень…

Оно в AUR’е лежит. Это плохой знак: туда попадают только несвободные приложения либо бажные

Искал подобную утилиту, остановился на rmlint. Тогда показалось самым простым вариантом для одноразового использования. Нужно было удалить дубли фоточек после объединения директорий с разных ПК.