If i move files from one folder to another a window pops up showing duplicate files that do already exist in the other folder. The problem is, besides the file size no other information is given if the files are equal. A button in this information window that offers a md5 or sha1 comparison of those files would help finding out if the files are real duplicates. Reproducible: Always Steps to Reproduce: 1. move files from folder A to B and make sure that some files of A do already exist in B. 2. a file comparison window pops up, but it has no information about md5 sha1 checksums 3.
To speed up the move operation the checksum operation should only processed on request.
Thanks for the report. I'll reassign to KIO (the library which handles copying/moving files, and which is also responsible for the "File exists already" dialog). For some earlier discussions about this issue, see http://lists.kde.org/?t=128584616700005&r=1&w=2
*** Bug 147996 has been marked as a duplicate of this bug. ***
*** Bug 389436 has been marked as a duplicate of this bug. ***
Wouldn't it be better (no hash collisions) and faster to use a bit-by-bit comparison over a hash function?
(In reply to postix from comment #5) > Wouldn't it be better (no hash collisions) and faster to use a bit-by-bit > comparison over a hash function? I agree. An bit-by-bit comparison would be sufficient in most cases. But, offering the option to display a hash could be helpful too. Imagine you have downloaded two different versions of a Linux distribution and their ISO file names are identical. You want to clean things up a bit and therefore delete one. But only the older one. And you want to keep the current one, which you downloaded days ago. But you no longer know exactly which of the two files was the more recent one. Unfortunately, the date is also identical because it was lost during a copying process. On the distribution's download page, you can display the hash of the latest version. If you move a file to the folder where the other file with the same name is located, but no longer know exactly which is the more recent one, then at this point at the latest, it would be useful to display the hash before moving and overwriting. Because you can then compare it with the hash on the download page. So how about the following option: If the file name is identical, a bit-by-bit comparison is performed first. You are then asked which file you want to keep, with the option of pressing a button called "show hash" to display the hashes of both files. When the user then presses this button, the hash of both files is also displayed. Now he can decide which file he wants to keep based on the information gained from the calculated and displayed hash for each file.
Addition to my previous comment. Alternatively, the hash could be calculated in the background if it is clear that these two files are not bit-identical. Then you would only need some kind of time indication in the message window that tells the user that the two files are different and which one he wants to keep until the hash is calculated. After it has been calculated in the background, it is displayed in the same message window. If, however, the user decides beforehand to keep one file and delete the other, the calculation process that is running in the background is aborted prematurely. This would have the advantage that the user would not have to actively press a button to calculate and display the hash, but that it would simply happen automatically in the background.