8

In the existing "File Already Exists" dialog box, the box you get when you try to drop a file in a folder that already has a file with that name, really shouldn't appear when the files are identical. I think it would be best if, when KDE detects that you are trying to drop a file in a folder with a file of the same name, it should go through the following steps:

1. Check if files have the same size. If they do, go on to step 2. If not, show the file already exists dialog.
2. Check if the files have the same checksum. If they do, go on to step 2. If not, show the file already exists dialog.
3. Do a byte-by-byte file comparison. If they are the same, tell the user this and ask if he or she wants to skip the file, rename it, or just delete the one being moved. If they are not the same, show the file already exists dialog.

good idea, but what about performance? If there are some big files it may take more than twice time, if in 3rd step it finally appears that files do not match. Your scenario is good for files smaller than 1mb, but for larger files...

I think same file name + same file size + compare 1st, last and some other random 10kb of bytes, it would be enough to mark them as POSSIBLY identical. Especially when we work with big files, as big files in most cases as music, movies, photos and other media, that in very rare case differs in a few bytes (unless some copying errors have occurred:) )

If the checksum is matches, it is extremely unlikely that they are not the same file. Perhaps it could tell you the checksum is the same and ask if you want to do a byte-by-byte comparison when the file is over a certain size.

So what's the point? If the files are already the same, does it really doesn't matter if you rewrite one with the other because they're the same. Unless you're worrying about the amount of time it takes, in which case by the time you finish the checksums, you would have already copied the file.

For example, let me copy a file from one partition to another:

Code: Select all

$ time md5sum movie.avi
513dd238cfaf26ebac03e1770cb9c6a2  movie.avi

real    0m28.550s
user    0m7.400s
sys     0m1.427s

$ time cp movie.avi ~/

real    0m57.393s
user    0m0.033s
sys     0m3.300s
$ echo '28.550*2'|bc
57.100

That's less than 0.2 second difference. And that's on different partitions - if it was the same partition, the move would be almost instant since all it does is change a few pointers.

Code: Select all

time mv movie.avi.copy movie.avi

real    0m0.524s

So basically all you want is to spend a lot of time doing absolutely nothing useful...

How are users supposed to now they are the same? You move a file from one folder to another and you get a dialog box that pops up that says that folder already has a file with that name. If it is a picture, you get a tiny thumbnail and the resolution, if it is anything else you get an icon and the size of the file. Based on this alone, you are supposed to make the decision about whether to rename the file, overwrite, or cancel the move. You have no way of knowing whether they are the same file or different files. This could leave you with a dozen copies of the same file in a folder because you didn't want to risk losing something so you decided to just rename them all. This idea is to eliminate this ambiguity. Instead of leaving you to guess whether the files are duplicates, it tells you. No matter how long it takes to do a byte-by-byte comparison, I can pretty much guarantee it will take longer for the user to go through and manually check to see if the files are different.

Well, comparison would be useful for me in that case, when I have to copy large amount of files to external disk (i.e backup). By now I have only one option, to wait during whole process and overwrite/skip manually, or overwrite automatically. Thats not good

The best solution, as I imagine now, is to have some sort of "Auto copy" mode. If file with the same name is found, check if they are equal, if so, just skip and don't bother me, if they are different - continue copying, but add the file to "ambiguous files" quene, so I could decide later what to do/ rename old file with _1 (so the newest would be accessible from eg bookmarks or scripts)/ rename new file with _1

I think this would be more useful.
When you have the same partition there is no significant usage.
But when you have different partitions there are several use cases:
-Backups. It happens quite often that you put files into the backup-folder. Newer files in this folder should not be overwritten. There aren't so much operations vice versa. But when you really need to apply the backup, nearly all files are different. The checking-overhead is not useful.
-FTP-Upload: Of course modification times are important. It nearly never happens that there are two identical files with different modification times. The checking would also be very slow.
-Other cases of copying:
There shouldn't be many identical files. When you think there are many of those files, you should use a tool.

Files with different dates are not necessarily different, and files with the same dates are not necessarily the same. I think these are completely different use-cases, so one is not better than the other. The whole point of this idea is to avoid having many copies of the same file because you are not sure whether the files are the same or not. The date has nothing at all to do with that.

When you overwrite the identical file you have two identical files.
When you skip copying the file you have two identical files.
What's the improvement?
Where wold you need it? What are the use-cases?

The User wrote:When you overwrite the identical file you have two identical files.
When you skip copying the file you have two identical files.
What's the improvement?
Where wold you need it? What are the use-cases?

What about renaming? When I copy or move a file to a folder, and I want to make sure I get that file in the folder, and I get a warning that there is already a file with that name in the folder, I have two options:

1. Rename the file, which could result in two identical files
2. Overwrite the old file, which could end up erasing something useful.

If I cannot afford to lose any existing data, my only option is 1. So I end up with two files. They may be identical, they may be different, I have no way of knowing. If I do this with hundreds of files, I could end up with a huge number of potential duplicates, which I would then have to go through and sort out which is a duplicate and which is not.

I just read this thread again and realized that the problem in most cases are not clicking on replace/skip button, but waiting when this menu rises.

Lets say you are copying a few large directories with hidden files. Now you have to wait for each time conflict about .directory rises. Its freakin annoying

I thin there should be some sort of option (list of options) to set how to thread duplicate files even before conflict rises.
And such sets could hold algorithms like use byte2byte or keep newer etc

Agree?