Bulk Renames Disregards Manual Edits
gThumb 3.6.1 on Mint Linux 19 (Tara) / 64-bit
Issue Experienced The act of performing a "bulk rename" of files in a given folder (i.e. by selecting all with Ctrl-A, then F2 and then confirming the file name template) results in any manual sequencing of files being disregarded. Please note that the steps below that are described in a failed state have previously been observed to work. Please also note that examination of the update log [via Update Manager] shows no updates to gThumb, although the feature described below has been previously seen to work.
Details
- Take a folder containing a collection of image files. Bulk select all images and use F2 to rename them to a common format - for example:-
Calvin and Hobbes - ###.jpg
Observe that the bulk rename works as expected.
-
Manually re-sequence the files by using a manual rename command [select the file via the browser tile, right click, select rename, enter a new value and press return to confirm the action]. Observe that the renamed file is correctly re-positioned in the browser view.
-
Once re-sequencing is complete, select the entire folder of files by using Ctrl-A, select a new name template and attempt a bulk rename of the entire library.
-
Observe that, this time [and all subsequent times] the rename completes successfully from a file rename perspective [all files are correctly named] but that the sequencing of the files is "undone" such that the file that was manually re-sequenced through local renaming is somehow magically and mysteriously returned to it's original position in the sequencing.
-
Bypass gThumb's "individual file rename" capability and rename the file using Nemo File Manager. For example, Change the file "Calvin and Hobbes 006.jpg" to "Calvin and Hobbes 000.jpg" to bring it to the first position in the folder. Note that the gThumb browser window immediately updates to show the change in file name. Perform a bulk rename of all files, this time changing the file name template to "Calvin and Hobbes ####.jpg" [adding an extra digit in the numeric counter] to avoid file name clashes]. Observe that the file name change completes successfully, BUT the relocated file is miraculously returned to the pre-rename position in the name sequence.
Various different permutations have been tried, without a change in result. Issue first spotted in folder connected via an NFS share to a QNAP NAS formatted to ext4. Issue reproduced on a local file system formatted to ext4. Attached screen images shown on local file system...
Description of Attached Image Evidence... GThumb001 - shows the original collection of images. Note that the numeric index in each file name is 3 digits long. Note also that the first and last images are very similar. Note that the image count ranges from 1-6 inclusive. GThumb002 - shows the collection after a manual file rename intervention to change the name of the file. Note that the 001 image has been renamed to 007. GThumb003 - shows the collection after using "Ctrl-A" and "F2" and then requesting a bulk file rename, editing the file name format to increase the number of digital from 3 to 4 [to eliminate the chance of file name clashes]. Note that the file rename has completed successfully [range returned to 1-6 inclusive, now 4 digits instead of 3]. Note, however, that the file in the first position [which had been moved to the end of the list] has automagically [sic] returned to the starting point.
As an experiment, I have tried manually deleting both /home/{me}/.thumbnails and /home/{me}/.local/share/gthumb, to attempt to purge any cached details, but this does not seem to make any difference to the issue.