Perhaps expected, not sure?
(Not complaining. Just trying to get a better understanding.)
Code: Select all
02/19/2022 05:03:59 PM - INFO: Unable to detect VLC Media Player 32-bit version 3 on your system
02/19/2022 05:03:59 PM - --------------------------------------------------
02/19/2022 05:03:59 PM - AllDup 4.5.13 PE
02/19/2022 05:03:59 PM - Search method: File name + File size + File content
02/19/2022 05:03:59 PM - Comparison method: Compare all characters of a file name
02/19/2022 05:03:59 PM - Comparison method: SHA-1 (160-Bit)
02/19/2022 05:03:59 PM - Option: Use database
02/19/2022 05:03:59 PM - 1.Source folder: W:\T\+o._e-fat-e-ccc-ruben2002-2
02/19/2022 05:03:59 PM - 2.Source folder: W:\+o._e-fat-e-ccc-ruben2002-2
02/19/2022 05:03:59 PM - Option: Compare only files between different source folders
02/19/2022 05:03:59 PM - Folder filter activated: 7
02/19/2022 05:03:59 PM - Filter type: Exclusive
02/19/2022 05:03:59 PM - 1.folder filter: e:\windows
02/19/2022 05:03:59 PM - 2.folder filter: e:\program files (x86)
02/19/2022 05:03:59 PM - 3.folder filter: e:\program files
02/19/2022 05:03:59 PM - 4.folder filter: ?:\system volume information
02/19/2022 05:03:59 PM - 5.folder filter: ?:\recycled
02/19/2022 05:04:00 PM - 6.folder filter: ?:\recycler
02/19/2022 05:04:00 PM - 7.folder filter: ?:\$recycle.bin
02/19/2022 05:04:00 PM - Determine file count of all source folders...
02/19/2022 05:04:43 PM - File count: 422,693
02/19/2022 05:04:43 PM - Scan: W:\T\+o._e-fat-e-ccc-ruben2002-2
02/19/2022 05:04:46 PM - Files filtered: 4
02/19/2022 05:04:46 PM - Scan: W:\+o._e-fat-e-ccc-ruben2002-2
02/20/2022 06:51:06 AM - Files filtered: 4
02/20/2022 06:51:11 AM - Found 210,914 duplicates with a total of 12.95 GB inside folder 'W:\T\+o._e-fat-e-ccc-ruben2002-2'
02/20/2022 06:51:11 AM - Found 210,805 duplicates with a total of 12.94 GB inside folder 'W:\+o._e-fat-e-ccc-ruben2002-2'
02/20/2022 06:51:25 AM - Scanned files: 422,693
02/20/2022 06:51:25 AM - Groups: 206,924
02/20/2022 06:51:25 AM - File comparison count: 214,856
02/20/2022 06:51:25 AM - Checksums created: 421,719
02/20/2022 06:51:25 AM - Database checksums stored: 421,719
02/20/2022 06:51:25 AM - Duplicates: 421,719 (99%) (25.89 GB)
02/20/2022 06:51:25 AM - Elapsed time: 13:47:12
02/20/2022 07:57:07 AM - --------------------------------------------------
02/20/2022 07:57:07 AM - Action 'Delete files' started.
02/20/2022 10:23:59 AM - Action 'Delete files' complete.
02/20/2022 10:23:59 AM - Files deleted: 210805 of 210805
02/20/2022 10:23:59 AM - Groups removed from the search result: 203102
02/20/2022 10:23:59 AM - Files removed from the search result: 210805
Paused it before it had finished.
Put the computer to sleep.
Then resumed the search at a later point.
On return, remaining search was relatively quick.
After that...
Expanding all the "folders" took a LONG time
Selecting all the wanted files for deletion, was quicker
Actually (hard) deletion; 210805 files, 12 GB, took --- 2:26:52
--- A LONG TIME
- granted, this was on a VERY slow 30kbps external USB2.0 hdd
Why the extended deletion time?
Due to the actual deletions, or due to the updating of the .db (sha1 hashes),
or perhaps due to the fact that all the files were small in size (or my slug of a drive)?
- /if/ due to the .db (.adb), then maybe there is a more efficient way to go about that?
Perhaps a separate "purge" routine for the .db (after the fact) that can go out &
check against non-existing files (on disk), mark those, then purge those (from the .db) en mass ?
Just how, when is the .db updated?
As in, is my assumption that you do that as the deletion routine runs correct?
---
Note that the above shown "Elapsed time:" is not real (cause the computer was put to sleep).
(I'll post more on that, another day.)