A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » General XP issues or comments
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

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



 
 
Thread Tools Display Modes
  #1  
Old August 10th 18, 08:37 AM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
Chris
external usenet poster
 
Posts: 177
Default There are so many - what do you use for a freewareduplicate file finder on Windows?

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 :-^)



Ads
  #2  
Old August 10th 18, 12:29 PM posted to alt.comp.os.windows-10,microsoft.public.windowsxp.general,alt.comp.freeware
R.Wieser
external usenet poster
 
Posts: 659
Default There are so many - what do you use for a freeware duplicate file finder on Windows?

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.


Quote:

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


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 02:36 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2004-2018 PCbanter.
The comments are property of their posters.