The Task
Hopefully, most of you know bulk renamer; if not, this is Thunar's handy plugin to rename many files together. The plugin is already very advanced and can perform many complex tasks. But sometimes, performing those tasks required more user interference than expected. Consider a case where you are renaming two files, and the new name for one file matches the old name of the second file. No issue arises if the second file is renamed first, and the bulk renamer works perfectly. But if the first file is renamed, it throws an error message as the filename already exists. In the case of two files, the user can resolve such errors manually, but it can become a very tedious task for a large number of files. So the job was to make the bulk renamer intelligent enough to identify the best order in which the files should be renamed so that all such errors are resolved entirely. A trivial usage case for it
is to be able to rename files named file4, file5 ... file13 to file1, file2 ... file10.
The Solution
Sorting is a critical player in the entire solution. The bulk renamer now tries three runs to rename a file. In the first run, the files are renamed in the user-specified order. If some files are not renamed successfully in this run, then the bulk renamer moves for the second run. Before starting the second run, all the failed files are first sorted in ascending order according to their current name. And then it tries to rename them again. But if still some files fail, it moves to the third run. Here the files are first sorted in reverse order and then renamed. The user is shown an error message if a file is still falling.
Under The Hood
With the support of Thunar's lead developers Alexander Schwinn (alexxcons), Sergios - Anestis Kefalidis, and Yongha Hwang (MShrimp4), the solution is implemented successfully in #MR267(https://gitlab.xfce.org/xfce/thunar/-/merge_requests/267). Implementing the three runs and sorting was not much of a big deal. But the real deal was to manage all the other systems that broke down due to the changes. One of the noteworthy was the undo option. But after rigorous manual testing, the entire system is working correctly and is ready to be used by general users.
The final system is now implemented as follows. The system stores four lists: one corresponding to the files that are renamed across all the runs, one corresponding to the files that are being renamed in the current run, one corresponding to the files that failed in the current run, and one corresponding to the files that are yet to be renamed in the current run. The system iterates over all the files in the list of pending files for the current run. For each file, it tries to rename it. If it is renamed successfully, then this file is added to the two lists corresponding to the files that are renamed successfully. And if it fails, then to the list corresponding to the failed one. Now at the end of each run, the system checks if there are files that still failing, or we can say if there are any files in the list of failed files. If there are, then these files are used as the pending files for the next run. If instead, all the files are renamed successfully, then there won't be any further runs. So it is not necessary that each time there will be three runs.
As discussed earlier, before starting a new run, the list of files yet to be renamed is processed accordingly. If the renaming of a file fails in the first or second run, then nothing is shown to the user. But if it fails in the third run, then the user is shown an error message, as the system can no longer resolve the conflict by itself. Accordingly, the user can either choose to cancel or to skip or undo all the changes made till now. If the user chooses to undo, then the list of all the files that were renamed successfully across all the runs is used, and all files in it are renamed back to their original name.
With this done, it's time for me to move on to my task for Xfce-Screenshooter, where I will implement custom actions support.