With the internet, it is inevitable that we hit the thought process of, “Hey! This is a cool picture, I will save it so I can send it randomly to one of my friends”, followed by a Right click -> Save as.... You proceed to save it with the same name as the image stored on the server (most of the time being just image.jpg).

This happens to me all the time. Sometimes I want to store the ones I download in a specific folder on my PC (because of course everyone is that organized, right?). But because you moved image.jpg to a folder, you now have 2 images named image.jpg and you want to have both in the same folder. Normally this is just solved by copying/moving the image with your file manager to the folder, and then you get a popup saying “Do you want to overwrite or keep both”. This makes sense because there are conflicts, so you click Duplicate, rename, keep both, whatever, The point is that you get to keep both in most cases.

Today I was in an oddly specific predicament, common to the general public, but I simply hand’t had to deal with it in a while. I had 2 images, one was in a folder, lets call this folder cheese, I had to move the new image.jpg from my downloads folder to the cheese folder now, so I did what I always did, move the file to the folder and click duplicate to keep bo… oh, it looks like its “preparing to move image.jpg to cheese”, alright, I will wait a few seconds, tic tac, nothing happened, I click cancel, and I just think “hm, I haven’t restarted my pc in some days now, I should be able to move it once I restart”, I thought of this because that same day I updated my system and in that update I updated the kernel headers, which leads to some weird stuff happening in my system until I restart, but nothing serious, so I continue with my day.

Once I reach the end of the day I shutdown the computer, go to sleep and think forget about the file, when I wake up while im doing my shit I spot the image on the downloads folder, I try to move it a gain to the cheese folder again, nothing happened AGAIN, I try to rename the image to something random, it moves with no problem, so I started to wonder, why?. Why do I have to rename when clearly I pressed the option to keep both images?.

I look a bit deeper at the cheese folder, turns out I already have BOTH image.jpg AND image.jpg (Copy) which is what nemo file manager does when you copy files, so by accident I try to copy instead of move now, IT WORKED, but why?. I undo and try the same but with a move instead, nothing happens for the third time, now im curious, why does this happen in the first place?.

For context: I use nemo as my file manager.

So I looked online and it turns out the eternal waiting was due to a bug in the nemo file manager, AND ITS BEEN THERE FOR 2 YEARS (linuxmint/nemo#3152, dont let the issue open date fool you, this bug in the code has been there for 2 years now and no one decided to open an issue until that moment).

Alright, SURELY someone tried to fix this, but it wasn’t merged because of some code quality or simply because it got abandoned, RIGHT? No, absolutely not. I was so wrong. NO ONE even tried to fix this jarring issue that’s so annoying, so I say to myself, “Ok, I will do it myself, how hard can it be?”, I clone the nemo repository, and I add this specific line to get_unique_target_file because it seems like a good starting point.

new_name = get_duplicate_name(editname, count, max_length);
printf("new_name: %s\n", new_name); // this one

Jackpot. When moving the file and reproducing the bug that printf gets printed at a blazingly fast speed in the console, and always with the same name, image.jpg (Copy), I was expecting something more like image.jpg, image.jpg (Copy) then image.jpg (Another copy) and finally start counting using numbers like this: image.jpg (3rd copy)…

But no, I decided to place a breakpoint on that same printf and see the stack trace, since in that function there isn’t a for loop nor a goto, so I go one function above, and I see:

dest = get_unique_target_file(src, dest_dir, same_fs, *dest_fs_type, 1);

So my thought was that count (The last argument from the get_unique_target_file function name) was saying in which iteration of the copy we were, because the number one seems to match with what the copy iteration would look like:

• 0. image.jpg
• 1. image.jpg (copy)
• 2. image.jpg (Another copy)
• 3. image.jpg (3rd copy)

So I decided to compare this to the copy operation, in which this bug was not present, and well, I was in SHAMBLES when I saw that the hardcoded 1 was instead a counter:

dest = get_unique_target_file(src, dest_dir, same_fs, *dest_fs_type, unique_name_nr++);

So I decided to do exactly the same. I added an int called unique_name_nr which was initialized to 1, the same as copy. It compiles, I launch it, and I move the file. It asks me if I want to duplicate or overwrite the old file, I click duplicate, I see in the console the same line (new_name: image.jpg (Copy)), and then my brain cells activate once more to see the NEW line. new_name: image.jpg (Another copy). I see the file manager, it finished, the file was moved successfully, my brain never released more dopamine than this exact moment, it’s just TWO LINES (1 line added for adding the variable to the function stack and edited one more to change the hardcoded one to the counter), AND NO ONE tried to fix this, amazing…

So that was it, now I can FINALLY download images from the internet without worrying about files having the same name, or if you are ever in this situation and you don’t encounter this bug, you can thank me. :)

1 day later edit: The PR merged