There are so many - what do you use for a freeware duplicate file finder on Windows?

Chris,

And neither can you trust your computer, OS or the program your find
those
duplicates with. Your point ?

Er, ok. With that attitude just shut down the computer and throw it out
the
window.

Exactly. So, please explain to me why you cannot trust that "last written"
time. And than why you still have a 'puter infront of you.

Regards,
Rudy Wieser

R.Wieser wrote:
Chris,

And neither can you trust your computer, OS or the program your find
those
duplicates with. Your point ?

Er, ok. With that attitude just shut down the computer and throw it out
the
window.

Exactly. So, please explain to me why you cannot trust that "last written"
time. And than why you still have a 'puter infront of you.

Because those timestamps can be modified by poorly written software or by
improperly copying/moving the files. Filesystem issues can also render
timestamps meaningless.

They aren't a reliable piece of information unlike a checksum.

In article , R.Wieser
wrote:

If handled with some care a good CD/DVD can easily outlast a drive.

i've slowly been migrating old cd/dvds to hard drives, only to find
that quite a few discs have issues. all of the discs were safely stored
and rarely used, until the migration.

most discs took a couple of minutes to read (i.e., normal), but some
took 10-15 minutes each to read and a few are not readable at all.

these were all quality cds, not the cheap crap.

the dyes in cd/dvds degrade. there's no way around that.

Magnetism fades away you know. And that becomes a problem when you do not
really use the drive (meaning: do not give it a chance to refresh sectors).

the main issue with hard drives that sit unused are frozen bearings.

however, fading away can be an issue with some ssds.

nothing lasts forever.

Chris,

Exactly. So, please explain to me why you cannot trust that "last
written" time. And than why you still have a 'puter infront of you.

Because those timestamps can be modified by poorly written software

So, vaguely referred to "poorly written software" can/will just change those
timestamps (but nothing more), and both your "diplicates finder" and your OS
do not fall in that range - for which reason please ?

or by improperly copying/moving the files.

When you do something "improperly" a lot more can be changed/damaged than
just that timestamp (owner, permissions). *Especially* when you use
"poorly written software". So again, your point ?

Filesystem issues can also render timestamps meaningless.

Lolz. You just *ran* into that one, didn't you ? With open eyes no less.

I mentioned that if you cannot trust those timestamps you also should not
trust your OS (or any programs on it) - to which you reponded that that was
a negative attitude - and now you're actually telling me that the OS could
well not be trustworthy in this regard ?

They aren't a reliable piece of information unlike a checksum.

True, but now you're trying to change the subject to "what is the best
method to detect changes between two files", which I'm not going along with.

Besides, the using of checksums/hashes has its own problems. Like the stored
hash and its file going outof sync. Or maybe some "poorly written software"
generating weak hashes with lots of collisions ... :-)

Bottom line, you still have not told me (apart from some FUD) why I should
actually distrust the last written timestamp. Or why you still own a
'puter.

Or in simpler words: why do you distrust that timestamp, but still trust
your 'puter for everything else ...


Also, you have lost sight of the reason what that timestamp used for. To
detect if the file has changed. If that timestamp has changed you may
assume that the file has changed, and thus needs to be re-backupped. And
that regardles of who actually changed it. Or why.

Regards,
Rudy Wieser

P.s.
If you have "poorly written software" on your 'puter I would suggest you
delete it and find something better. :-p

In article , R.Wieser
wrote:

Also, you have lost sight of the reason what that timestamp used for. To
detect if the file has changed. If that timestamp has changed you may
assume that the file has changed, and thus needs to be re-backupped. And
that regardles of who actually changed it. Or why.

except when the time stamp changes simply by copying a file yet its
contents did *not* change. in other words, two files with different
time stamps can be identical.

On Wed, 8 Aug 2018 07:11:21 -0000 (UTC), Chris
wrote:

Shadow wrote:
On Tue, 7 Aug 2018 20:16:52 +0100, "J. P. Gilliver (John)"
wrote:


2 copies. It only takes a few more minutes and DVDs are dirt
cheap.

And unreliable. Writable DVDs are not suitable for archiving.

Why not just use an external hard drive? Cheaper, simpler and more
reliable.

I'm still recovering from the last crash. 2 TB of backups or
archives or whatever down the drain. The drive lasted 4 months. No
warranty possible as it contains personal files. You have to hand it
in so Seagate can "refurbish it" and sell it to another sucker, and
probably sell all your data once they replace the controller.

Checking
1998 programming - TDK CD-R 650MB 74 Min (everything from Softice to C
compilers, assemblers, editors, tutors etc. Sadly, most installers are
16 bit)
2000 books - Memorex
2000 Diablo 2 - 2 disks TDK

All 100% readable with DVDDisaster. Use decent media and keep it in a
cool, dark and dry place.

Checking
Megaupload - keep your files safe on "The Cloud"
Gone - 100% failure
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

In article , Shadow
wrote:

Why not just use an external hard drive? Cheaper, simpler and more
reliable.

I'm still recovering from the last crash. 2 TB of backups or
archives or whatever down the drain. The drive lasted 4 months. No
warranty possible as it contains personal files.

next time, encrypt it, and also make more than one backup.



Checking
Megaupload - keep your files safe on "The Cloud"
Gone - 100% failure

a cloud service focusing on piracy shut down. imagine that.

meanwhile, amazon, google, apple, microsoft, dropbox, etc. are still
around and not likely to go away any time soon, certainly not in our
lifetimes.

hard drives also crash, as did yours. 100% failure there too.

nothing is guaranteed, which is why one should have *multiple* backups
and in mulitple locations.

ask the people affected by the california wildfires, or the hurricanes
last year, where everything in their houses was destroyed, whether they
prefer a cloud backup or a local (and now non-existent) backup.

On Wed, 08 Aug 2018 12:17:32 -0400, nospam
wrote:

In article , Shadow
wrote:

Why not just use an external hard drive? Cheaper, simpler and more
reliable.

I'm still recovering from the last crash. 2 TB of backups or
archives or whatever down the drain. The drive lasted 4 months. No
warranty possible as it contains personal files.

next time, encrypt it, and also make more than one backup.

Yes, still trying to figure out the most reliable encrypted
backup.A real time sync would be best, as in just replace the bad
drive(assuming the backup goes bad) and it would boot into your old
workspace. But encrypted ? I could just carry on backupping films and
photos to DVDs.
As to Cloud services, I'll take my luck with hurricanes and
wildfires. Until hurricanes and wildfires figure out how to sell your
data too, of course.
Are Seagate and Western Digital the only choices left ? So
much for capitalism.

Any ideas as to an encrypted system, "type password at boot"
and with a real-time mirror to a second HD, ie, anything changed in
main drive will also be changed in second drive ?
[]'s



Checking
Megaupload - keep your files safe on "The Cloud"
Gone - 100% failure

a cloud service focusing on piracy shut down. imagine that.

meanwhile, amazon, google, apple, microsoft, dropbox, etc. are still
around and not likely to go away any time soon, certainly not in our
lifetimes.

hard drives also crash, as did yours. 100% failure there too.

nothing is guaranteed, which is why one should have *multiple* backups
and in mulitple locations.

ask the people affected by the california wildfires, or the hurricanes
last year, where everything in their houses was destroyed, whether they
prefer a cloud backup or a local (and now non-existent) backup.
--
Don't be evil - Google 2004
We have a new policy - Google 2012

In message , Shadow
writes:
[]
Any ideas as to an encrypted system, "type password at boot"
and with a real-time mirror to a second HD, ie, anything changed in
main drive will also be changed in second drive ?
[]
I think one of the RAIDs (0 or 1?) will do the second bit; I assume they
can be used with type-password-at-boot type systems, but I don't know.
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

The motto of the Royal Society is: 'Take nobody's word for it'. Scepticism has
value. - Brian Cox, RT 2015/3/14-20

In article , J. P. Gilliver (John)
wrote:

Any ideas as to an encrypted system, "type password at boot"
and with a real-time mirror to a second HD, ie, anything changed in
main drive will also be changed in second drive ?

I think one of the RAIDs (0 or 1?) will do the second bit; I assume they
can be used with type-password-at-boot type systems, but I don't know.

most nases support encryption, regardless of which raid it's set up as,
and some of which have a hardware encryption chip so there's little to
no impact on performance.

and raid 0 is for performance, not backups.

Chris,

Originally Posted by me

Also, you have lost sight of the reason what that timestamp used for.

Maybe even put simpler:

# When the "last changed" times differ (but the contents are the same) than
:

1) the "duplicate finder" will consider them as different. The negative site
of that will be that you will have two copies instead of the desired single
one.

2) the backup program makes a copy of it. The negative side of that would
be that it needs more time and storage space to complete.

# The chance that both files "last changed" times do actually match (after
some "poorly written software" has altered it) is rather small
(understatement).

In other words, a false positive (the files are considered the same when
they are not) is rather unlikely, and a false negative isn't destructive.


But even if those "last changed" timestamps would match (like after some
PEBKAC has run a "touch" on its whole drive), its just *one* part in the
whole "are the files the same" check, which includes size and (when
backupping/comparing with a backup) the full filepath (among others).

Regards,
Rudy Wieser

On Wed, 8 Aug 2018 23:50:06 +0100, "J. P. Gilliver (John)"
wrote:

In message , Shadow
writes:
[]
Any ideas as to an encrypted system, "type password at boot"
and with a real-time mirror to a second HD, ie, anything changed in
main drive will also be changed in second drive ?
[]
I think one of the RAIDs (0 or 1?) will do the second bit; I assume they
can be used with type-password-at-boot type systems, but I don't know.

I'm still recovering from a rather large surgery I had 5 days
ago, and my head is full of narcotics. I hate narcotics, having
trouble thinking. In my perception, the Bouffant's posts have gone
from extremely imbecilic to just stupid. That's how bad my thinking
process is ATM.

Re backup = That's what I want. I don't mind paying for a
second or third HD if they are kept strictly in sinc, and preferably
if the backup drives do not appear in explorer. I would still backup
or archive personal photos, movies, letters, documents etc to DVDs, as
they are irreplaceable, and it's possible a power surge could burn out
both HDs at once.
So a RAID with only the basic boot-up files not encrypted, and
no network access until the drives have been unencrypted and firewalls
etc are all working.
How would I go about that ?
[]s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

Arlen Holder wrote:

Jesus...There are so many - what do you use for a freeware duplicate file
finder on Windows?

Googling, I find so many it's not funny...where you know there's a problem
when no two articles even have agreement on the top few.

First I tried the canonical duplicate file remover from Microsoft...
Microsoft Duplicate File Remover
https://www.microsoft.com/en-us/p/duplicate-file-remover/9nblggh4sqnp

But it was too much GUI and too little customization.
http://www.bild.me/bild.php?file=9081255duplicatefileremover.jpg

Then I searched for better duplicate file removers, and was aghast that
there is very little consensus among the "reviews" (many of which, I know,
are simply shills).

The Best Duplicate File Finder for Windows
* dupeGuru https://dupeguru.voltaicideas.net/
* Ccleaner https://www.ccleaner.com/ccleaner
https://lifehacker.com/the-best-duplicate-file-finder-for-windows-1696492476

What Is the Best Duplicate File Finder?
https://www.easyduplicatefinder.com/best-duplicate-file-finder.html

How to Find and Remove Duplicate Files on Windows
https://www.howtogeek.com/200962/how-to-find-and-remove-duplicate-files-on-windows/

5 Best Free Duplicate File Finder Software for Windows
https://www.cisdem.com/resource/best-free-duplicate-file-finder-for-windows.html

5 Best Free Duplicate File Finder and Remover
http://perfectgeeks.com/free-duplicate-file-finder-remover/
https://www.top5freeware.com/duplicate-file-finder
* Auslogics Duplicate File Finder https://softfamous.com/auslogics-duplicate-file-finder/
* AllDup https://softfamous.com/alldup/
* CloneSpy http://www.filesriver.com/app/117/clonespy
* Fast Duplicate File Finder http://www.filesriver.com/app/118/mindgems-fast-duplicate-file-finder
* Anti-Twin http://www.filesriver.com/app/119/anti-twin

26 Best Free Duplicate File Finders
https://listoffreeware.com/list-of-best-free-duplicate-file-finder/

What do you use for a freeware duplicate file finder on Windows?

I recently did a fair bit of searching and settled on a commercial
program, Duplicate Cleaner Pro, after briefly trying the free version.
Basically because it looked more versatile than most. And I'm not so
stingy about buying stuff nowadays.

https://www.duplicatecleaner.com/

Too early to give a useful assessment, but I've found no serious issues
on the few occasions I've used it to prune large folders of photos.

Terry, East Grinstead, UK

R.Wieser wrote:
Chris,

Exactly. So, please explain to me why you cannot trust that "last
written" time. And than why you still have a 'puter infront of you.

Because those timestamps can be modified by poorly written software

So, vaguely referred to "poorly written software" can/will just change those
timestamps (but nothing more), and both your "diplicates finder" and your OS
do not fall in that range - for which reason please ?

I don't have duplicates finder. The OS is written to a much higher standard
than most userland apps.

or by improperly copying/moving the files.

When you do something "improperly" a lot more can be changed/damaged than
just that timestamp (owner, permissions). *Especially* when you use
"poorly written software". So again, your point ?

You just made it for me. Checksums are much better than last changed
timestamps.

Filesystem issues can also render timestamps meaningless.

Lolz. You just *ran* into that one, didn't you ? With open eyes no less.

I mentioned that if you cannot trust those timestamps you also should not
trust your OS (or any programs on it) - to which you reponded that that was
a negative attitude - and now you're actually telling me that the OS could
well not be trustworthy in this regard ?

Whoosh! The OS and filesystem are not synonymous.

They aren't a reliable piece of information unlike a checksum.

True, but now you're trying to change the subject to "what is the best
method to detect changes between two files", which I'm not going along with.

This was my original point to Shadow which you butted in on. Is there's one
of us who's changing the subject, it's you.

Besides, the using of checksums/hashes has its own problems. Like the stored
hash and its file going outof sync. Or maybe some "poorly written software"
generating weak hashes with lots of collisions ... :-)

Nothing's perfect. However comparing timestamps is much worse than
checksums.


Also, you have lost sight of the reason what that timestamp used for. To
detect if the file has changed.

No. That is not what a timestamp is for. All it tells you is when it was
last re-saved. You cannot make any judgement on state change.

For example I have a file with a timestamp of "01 April 2015 11:32:05". Has
the file changed?

If that timestamp has changed you may
assume that the file has changed,

Nope. A file can be opened and re-saved without any changes occurring.

Why is all this so hard for you to understand?

P.s.
If you have "poorly written software" on your 'puter I would suggest you
delete it and find something better. :-p

Well, it is Windows. It comes with the territory :-^)

Chris,

The OS is written to a much higher standard than most
userland apps.

Kiddo, you just told me that even mere moving or copying could muck around
with the timestamp, so where are you taking that "higher standard" from ?

Also, you seem to be thinking that for "badly written software" changing
that "last written" timestamp is something that a program can "just do" -
without any particulary intent or reason. Newsflash: Its harder than you
think. :-)

You just made it for me. Checksums are much better than last
changed timestamps.

I would strongly suggest you read it again. I was making a case where doing
something "improperly" would most likely damage a lot more than just a
timestamp. In other words, the changed timestamp would than be the least
of your concerns.

Checksums are much better than last changed timestamps.

Again trying to change the subject ?

Whoosh! The OS and filesystem are not synonymous.

Just like checksums and hashes are not. You don't give a flying **** about
it, but now trying to using distinction like that ? Really ?

And yes, I'm quite aware of it. But I mostly do not make a point of it
(especially not when its not relevant to the problem) as it just confuses
the issue. Just like I have not pointed out the difference between a
checksum and a hash.

Also, when was the last time you bought your OS and your filesystem
seperatily ? Lets guess ... Never ?

True, but now you're trying to change the subject to "what is the best
method to detect changes between two files", which I'm not going along
with.

This was my original point to Shadow which you butted in on. Is there's
one
of us who's changing the subject, it's you.

I use a duplicate finder to check that the ones I have backed
up to DVD are identical to the ones on disk. Good duplicate
finders use hashes and checksums.
[]'s

You could cut out the middleman and store the checksums with your
backups.
The issue with using a duplicate finder down the line is that if it shows
they're different, you don't know which has changed.

This is what I responded to : Using a duplicate finder as part of a backup
process. Would you like to try again ?

Nothing's perfect. However comparing timestamps is much worse
than checksums.

You have said that several times, but no matter what I say you have not even
*tried* to come up with anything underbuilding it - other than a vague
hand-waving to "poorly written software", which I think I shot outof the
water.

No. That is not what a timestamp is for. All it tells you is when it was
last re-saved. You cannot make any judgement on state change.

True. The question is, if you have not changed anything, why would you
re-save ? And what if its intentional (the file is ment to be regarded as
the most recent one) ?

For example I have a file with a timestamp of "01 April 2015 11:32:05".
Has the file changed?

Im upping you one: How does your "lets take a checksum" indicate a change
(or not) ?

And when you figured that out, do you think I may also do a compare (of that
timestamp against another one) ?

If that timestamp has changed you may
assume that the file has changed,

Nope. A file can be opened and re-saved without any changes
occurring.

Yes, thats a possibility. But notice the "you may assume that" (for most,
if not all, intents and purposes). In other words, I'm quite aware of it.

Also, already replied to (repeating yourself doesn't make your case
stronger)

Why is all this so hard for you to understand?

It isn't, and I've given several indications of that in my previous posts.



But I have the same question for you: With all my explanation, why don't you
understand that "just" using the "last written" timestamp normally works,
and when not it isn't destructive ?

Also, how is it that you seem to be acutily aware of how bad using a
last-written timestamp is, but have given no indication to the problems your
preferred method of using hashes has ? In short: You are not even
*trying* to compare the two.


And FYI, comparing hashes is just *one* step in the process. Which includes
generating them from full contents of the sourcefiles file (costs time). If
the compare is done to a backup hashes need to be generated for them too
{1}. Than comparing them and when they match *compare the actual file
contents* (costs time) to be sure they are really the same (and not just
hash collisions).

{1} If you are thinking about storing the hashes of the backupped files
somewhere that file can get lost, altered or corrupted. Or, even worse,
someone could alter a file on the backup which throws the list outof sync.

My suggested "compare 'last written' timestamps" (among a few things) do not
involve any of that ...

Bottom line: both methods have their pros and cons. The method involving
hashing will find *all* duplicates, but will cost a *lot* of time. The
"last written" method is fast, but could miss a few files which contents
have not actually changed.


But lets end this, shall we ? You seem to be convinced that I'm not
understanding any of it, as I'm convinced that its you (who doesn't even
try). :-)

Regards,
Rudy Wieser