Topic: Windows - Command line and Dialog driven command

[tjr]

Tim:

While TonyT's explanation is correct, it doesn't provide the correct solution to your problem. When doing a comparison of a local copy to a remote/backup copy the only correct what to do it is compare a SHA1 hash of the local file to a SHA1 hash of the remote file. If they are different then the local copy needs to be moved to the remote location.

You seem to be confusing two very different questions:

1.  Are two files different?

2.  Which of two files was more recently changed?

I must have missed this one.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.

Hate to disagree. 

Comparing the contents of two files does not tell you which was modified more recently.  The only thing a content based comparison tells you is if the contents of the two files are different, and nothing else.

Keeping in mind that the file's timestamp is meaningful, even if the file's contents are the same, the file that was changed more recently should still be used, so IMHO, there is no point to a content comparison of the files.

You have every right to disagree but you are 100% wrong, especially in the situation Tim's code represents. For a simple backup system local file is master and remote file is slave, there is no deviating from this. If for some reason the remote file has a datetime stamp that is greater than that of the local file the code FAILS, plain and simple. Heck even if they have the same datetime stamp the remote file could have completely different content than the local "master" file. If you don't think it's possible do a google search and you will see that I'm right.

This is very basic computer science stuff and comparing file content is the standard method for almost every modern backup utility and version control system out there.

[TonyT]

If for some reason the remote file has a datetime stamp that is greater than that of the local file the code FAILS, plain and simple.

Thanks for making my point.

What you say above just about sums it up. There's no need to compare the contents of the files, because if the comparison of their timestamps indicates that the local file is newer than the backup, the backup proceeds, and otherwise it does not.

The only thing a content comparison can do, is check to see if the files are identical, which eliminates the need to back up the file. Since the chances that two files with different time stamps are identical are so small, there is nothing saved by comparing their contents, and doing that only serves to require the backup to take much longer.

Heck even if they have the same datetime stamp the remote file could have completely different content

Sorry, but what you say above seems to confiirm that you're confused.

A simple backup process is just that: Simple.  If the existing backup is older than the local file, the backup proceeds, and otherwise it does not. Whether the files are different, or not isn't important, only that the local file is newer than the backup.

[tjr]

If for some reason the remote file has a datetime stamp that is greater than that of the local file the code FAILS, plain and simple.

Thanks for making my point.

What you say above just about sums it up. There's no need to compare the contents of the files, because if the comparison of their timestamps indicates that the local file is newer than the backup, the backup proceeds, and otherwise it does not.

The only thing a content comparison can do, is check to see if the files are identical, which eliminates the need to back up the file. Since the chances that two files with different time stamps are identical are so small, there is nothing saved by comparing their contents, and doing that only serves to require the backup to take much longer.

Heck even if they have the same datetime stamp the remote file could have completely different content

Sorry, but what you say above seems to confiirm that you're confused.

A simple backup process is just that: Simple.  If the existing backup is older than the local file, the backup proceeds, and otherwise it does not. Whether the files are different, or not isn't important, only that the local file is newer than the backup.

If this simple concept escapes you then god help you with the rest of your software writing. I've mentioned it several times yet you seem to be unable to grasp the concept that there is the possibility that a "backup file" has a timestamp which shows a newer timestamp than a "master file" nor the concept that a remote file can contain the same timestamp yet contain different content.

This is common sense stuff, we aren't "hacking the gibson" here.

over and out,
Tim "Zero Cool" Riley

[TonyT]

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

[TonyT]

If this simple concept escapes you then god help you with the rest of your software writing. I've mentioned it several times........

No, you haven't mentioned it several times.. you're just making it up as you go along.

You originally asserted that a hash of the files must be done.

Now you're saying "what if the existing backup is newer than the file to be backed up"., as if doing hash of the files is going to tell that.....

You're basically making things up as you go along to save face, which is fine, but I've got more interesting things to do.

[Tuoni]

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

That entirely depends on your definition of "correct".

Will the following compile?

Code: [Select]

if (x > y) ;
        y++;

Yes it will.  Is it correct?  I would say not.  What does it do?  Almost certainly not what you wanted it to.  However, the code is perfectly VALID.

So will the compiler compile incorrect code?  Well, it will only compile code which it knows can be executed.... that doesn't mean that the code is correct and works as expected by the programmer.

If you don't believe me, why do programs like FxCop exist, and why does it warn you about certain code practises which will happily go through a compiler?

[tjr]

If this simple concept escapes you then god help you with the rest of your software writing. I've mentioned it several times........

No, you haven't mentioned it several times.. you're just making it up as you go along.

You originally asserted that a hash of the files must be done.

Now you're saying "what if the existing backup is newer than the file to be backed up"., as if doing hash of the files is going to tell that.....

You're basically making things up as you go along to save face, which is fine, but I've got more interesting things to do.

Like I said, I've said it several time.

No I'm not confusing anything. Looking at his code, and the fix you provided, coupled with his comment that this is a one way sync; I don't see the correct solution anywhere. With his way and your way I could open a drawing in the "backup" directory, replace his floorplan with a nice sketch of a pony, and if that isn't one of the files he recently changed locally he won't have anything remotely correct in his archive.

That is why the only correct way to do backups of anything is to compare hashes.

[TonyT]

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

That entirely depends on your definition of "correct".

You're getting off the main point, which is that for *any* type, a compiler cannot infer what 'is greater than', or 'is less than' means, and if the compiler cannot infer what that means and the type is not based on an intrinsic type for which the compiler *can* infer a meaning, the compiler should not compile code that uses > or < on a type that does not provide overloads for them.

A compiler for example, doesn't know what a 3d vector is, so it can't generate code that returns a bool indicating if one 3d vector 'is greater than' another.

It's just that plain and simple. 

[Tuoni]

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

That entirely depends on your definition of "correct".

You're getting off the main point, which is that for *any* type, a compiler cannot infer what 'is greater than', or 'is less than' means, and if the compiler cannot infer what that means and the type is not based on an intrinsic type for which the compiler *can* infer a meaning, the compiler should not compile code that uses > or < on a type that does not provide overloads for them.

A compiler for example, doesn't know what a 3d vector is, so it can't generate code that returns a bool indicating if one 3d vector 'is greater than' another.

It's just that plain and simple. 

I'm not getting off the point, you were telling me that == is a valid way in OOP languages to compare two strings for equality of value.  That is fundamentally incorrect.  You also said that if an operator doesn't cause the compiler to bug out, it's valid to be used (and in fact SHOULD be used) in that case.  Also incorrect.

[TonyT]

What I said was that if the compiler doesn't throw an error, that doesn't mean that the code is correct and works how you want it to.

I believe a compiler should not compile code that it can determine to be incorrect, or likely to be incorrect.

That entirely depends on your definition of "correct".

You're getting off the main point, which is that for *any* type, a compiler cannot infer what 'is greater than', or 'is less than' means, and if the compiler cannot infer what that means and the type is not based on an intrinsic type for which the compiler *can* infer a meaning, the compiler should not compile code that uses > or < on a type that does not provide overloads for them.

A compiler for example, doesn't know what a 3d vector is, so it can't generate code that returns a bool indicating if one 3d vector 'is greater than' another.

It's just that plain and simple. 

I'm not getting off the point, you were telling me that == is a valid way in OOP languages to compare two strings for equality of value.  That is fundamentally incorrect.  You also said that if an operator doesn't cause the compiler to bug out, it's valid to be used (and in fact SHOULD be used) in that case.  Also incorrect.

Sorry, I don't want to get into it with nit-pickers with nothing better to do than mince words to try to find flaws in them.
 
In most well-designed OOP programming languages, both of those assertions are true. Java isn't a well-designed programming language, in my opinion.

Since there are many "oop languages", some obscure, half-baked, and rarely used, One can also say that there is nothing at all that *all* of them have in common, nor is there any rule or principle that every one of them supports, which means, that you're not really saying much of anything by asserting that what I've said about operators is not true for "*any*" oop language.

It is true for most well-designed ones.

So, what you're up to here is making an issue out of my use of one word: "any" as in "any oop language".

Well sorry, I'm not interesting in feeding cheap, opportunistic, pot-shots based on relatively meaningless minutae and nit-picking of words.

[TonyT]

...and Dan's disassembly shows, that in this case, using 'Compare' would be a more expensive operation than just using the overloaded operator >, as it just compares the internal long values...

Hi Glenn. 

I've learned the hard way, that Reflector's disassembly doesn't always tell the true story.

It quite often generates code that's deliberately verbose and seemingly inefficient, mainly for the sake of readability. The most common example is generating code that uses IEnumerable directly, where the original source code may have used foreach(). Hence, it can also often involve using variables where the original source may not have, and is actually more efficient.

I suppose that since we can look at much of the framework source code now, that might offer a more definitive answer.

[Tuoni]

I like how you went back and HEAVILY edited your post a page back!  See, if you had responded like that in the first place, I would have been more inclined to treat you as someone able to communicate on that level.  When you get to the stage of "NO U" I will talk back to you as such.  

For anyone who comes across this in future, the post I was responding to (which has since been changed to actually be something worthwhile) was:

you're saying that if an operator doesn't cause the compiler to throw a fit in *ANY* OOP language, the code is valid?  I disagree...

If the compiler doesn't know how to compare the types, the compiler *will* throw a fit.

What kind of compiler would let you use an operator on a type, if the compiler doesn't know what code it must generate to perform the comparison ??

Why do you think the compiler throws the error?  It does that because it must generate code for the operation, and if it doesn't know what code to generate (e.g., it doesn't know how to compare the operands), then how can there not be an error?

You must be kidding, right?

Sorry.... I think that alone makes any further discussion pointless.

This is why people quote posts when they respond to them.

[It's Alive!]

*sigh*

[TonyT]

I like how you went back and HEAVILY edited your post a page back!  

I like how you troll for opportinties to nit-pick other people's words.

Shame you don't have anything better to do with your time.

[Glenn R]

...and Dan's disassembly shows, that in this case, using 'Compare' would be a more expensive operation than just using the overloaded operator >, as it just compares the internal long values...

Hi Glenn. 

I've learned the hard way, that Reflector's disassembly doesn't always tell the true story.

It quite often generates code that's deliberately verbose and seemingly inefficient, mainly for the sake of readability. The most common example is generating code that uses IEnumerable directly, where the original source code may have used foreach(). Hence, it can also often involve using variables where the original source may not have, and is actually more efficient.

I suppose that since we can look at much of the framework source code now, that might offer a more definitive answer.

Hey Tony,

I realise that reflector can be verbose, but not that verbose. In future I'll treat it with a grain of salt I suppose. Nice reminder about the framework source - I will have to investigate it further.

Cheers,
Glenn.