Uploaded image for project: 'Picard'
  1. Picard
  2. PICARD-2707

Re-saving album with different tag value capitalization does not rename folders

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • 2.9
    • File Move & Rename
    • None
    • Windows 10 22H2

      Title says it all. When you save a previously tagged album with modified capitalization of some tag value the filename script uses, the new capitalization is not reflected in the destination path. This is the case for both folders and files in place. However, if a file is being moved out of its original location, the file's name does change to reflect the new capitalization.

      Steps to re-produce:

      1. Add a previously tagged album to Picard.
      2. Change the capitalization of any tag value that is used as part of the filename script in use. For example, the album title if that forms part of the destination path as dictated by the filename script in use.
      3. Click "Save".

          [PICARD-2707] Re-saving album with different tag value capitalization does not rename folders

          I had considered this when implementing PICARD-1991 and PICARD-1992. This is somewhat tricky to implement.

          The core thing is, that because Windows is case insensitive independent of the casing it is considered the same directory. So you can't create a second directory with separate casing.

          The above tickets implemented the case changes for individual files. This would need to be done for every directory in the hierarchy. So instead of just saving the file Picard would need to check each directory for casing changes and apply the renaming.

          Things get complicated by a few things:

          • In quite a few cases renaming just the case does not directly work. Instead the file / directory needs to be temporarily renamed into something else and then back into the proper name. This is the case on Windows with FAT32 or exFAT file system or on case-insensitive Linux file systems. Doing this for directories might trigger some unwanted side effects, as the actual directory stops to exist temporarily.
          • Likely not the entire path should be considered but only the part of directories inside the base directory. You likely don't want "C:\Users" getting renamed to "C:\users".

          Overall it ads quite some complexity to the file renaming / moving for a case where the file essentially is kept in place without effective path change.

          Philipp Wolfer added a comment - I had considered this when implementing PICARD-1991 and PICARD-1992 . This is somewhat tricky to implement. The core thing is, that because Windows is case insensitive independent of the casing it is considered the same directory. So you can't create a second directory with separate casing. The above tickets implemented the case changes for individual files. This would need to be done for every directory in the hierarchy. So instead of just saving the file Picard would need to check each directory for casing changes and apply the renaming. Things get complicated by a few things: In quite a few cases renaming just the case does not directly work. Instead the file / directory needs to be temporarily renamed into something else and then back into the proper name. This is the case on Windows with FAT32 or exFAT file system or on case-insensitive Linux file systems. Doing this for directories might trigger some unwanted side effects, as the actual directory stops to exist temporarily. Likely not the entire path should be considered but only the part of directories inside the base directory. You likely don't want "C:\Users" getting renamed to "C:\users". Overall it ads quite some complexity to the file renaming / moving for a case where the file essentially is kept in place without effective path change.

          David Kellner added a comment -

          Interesting, my initial guess would have been that it's an issue with the Windows file explorer, which can usually be solved by refreshing the view (F5). Because Windows file systems are case-insensitive, a capitalization change is not considered a change and the view doesn't refresh automatically.

          But after having tested this myself, I am able to confirm this is a different issue and I guess that Picard contains (OS specific) code to check if the file location has actually changed before moving files.

          David Kellner added a comment - Interesting, my initial guess would have been that it's an issue with the Windows file explorer, which can usually be solved by refreshing the view (F5). Because Windows file systems are case-insensitive, a capitalization change is not considered a change and the view doesn't refresh automatically. But after having tested this myself, I am able to confirm this is a different issue and I guess that Picard contains (OS specific) code to check if the file location has actually changed before moving files.

            Unassigned Unassigned
            affronttonature affronttonature
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:

                Version Package