File Moving Operation Alters Original Mtime

[Neher-Veem]

Bug Description

I might be a bit cautious, but every time I search for duplicate files, I follow a process: I first obtain the list of candidates, select the ones I want to delete, and then move them to another directory within the same filesystem. Afterward, I manually review them and perform another search using the original directory as the "reference" and the new one as the "normal."
I was surprised to find that Czkawka appears to copy, save, or otherwise touch the original files, rather than simply moving them. Moving a file within the same filesystem is an atomic operation that should not alter the mtime.

Steps to reproduce:

1. Create a copy of any file using the following command:
   rsync -avhtU /my_dir/my_file /my_dir/copy_of_my_file
   This preserves the timestamps as much as rsync allows in Linux.
2. Search for duplicates with Czkawka. When you get the results, select copy_of_my_file, check it, and then move it to a different location using the Move button.
3. Open a terminal and run:
   stat /my_dir/my_file /some_other_dir/copy_of_my_file
   Review the output, paying special attention to lines starting with "Modify:" and also note that the Inode number has changed.

** Expected behavior**

You can either use an atomic move operation of the filesystem to avoid altering the mtime, or use rsync to preserve the mtime and other attributes. Alternatively, in the worst case, please make it clear that moving will involve copying and then deleting the original file, which will result in the loss of the mtime and potentially other attributes.

System

• Czkawka Version 7.0.0 - 19.02.2024r
• OS version: Linux Mint 21.3
• Installation method: Binary, AppImage and Flatpak. All of them showed the same behavior