| Summary: | Provide a md5, sha1 checksum comparison for duplicate files that are found after a file move operation | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | kreuzritter2000 |
| Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | bughunt, bugseforuns, ch.trassl, f.alexander.wilms, frank78ac, kdelibs-bugs-null, munoz.roberto, nate, postix |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
kreuzritter2000
2014-07-09 14:16:46 UTC
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. *** Bug 222998 has been marked as a duplicate of this bug. *** *** Bug 502419 has been marked as a duplicate of this bug. *** |