Package: duperemove
Version: 0.11.2-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I ran the following command:
duperemove -dr --hashfile=/root/$VOLUME.hash /mnt/$VOLUME
with /mnt/$VOLUME being a btrfs device. This has worked before. (I plan
do rerun the job at a later point of time to check reproducability,
however this process takes several hours so it won't be possible today)

   * What was the outcome of this action?

The action was aborted with the following messages:

[28851/28851] (100.00%) csum: /mnt/$VOLUME/$somefile
Total files:  28851
Total extent hashes: 961397
Loading only duplicated hashes from hashfile.
Hashing completed. Using 2 threads to calculate duplicate extents. This may 
take some time.
ERROR: hash-tree.h:80
ERROR: hash-tree.h:80
[stack trace follows]
duperemove(print_stack_trace+0x2e) [0x55584fc9c93e]
duperemove(+0xcd2c) [0x55584fc9ed2c]
duperemove(+0xd0ac) [0x55584fc9f0ac]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x7b9a4) [0x7f3ac07079a4]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x7b0bd) [0x7f3ac07070bd]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7) [0x7f3ac02f7ea7]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f3ac0481def]
Aborted

   * What outcome did you expect instead?
duperemove should have find duplicate files and deduplicate them.

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=nl_BE:nl
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages duperemove depends on:
ii  libc6         2.31-12
ii  libglib2.0-0  2.66.8-1
ii  libsqlite3-0  3.34.1-3

duperemove recommends no packages.

duperemove suggests no packages.

-- no debconf information

Regards,
Benedikt Wildenhain

Reply via email to