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

Unexpected results in File Naming Script

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • 2.8.5
    • Scripting
    • None
    • Windows 10 22H2
      OS Build 19045.2486

      I am running into what I feel is a bug in the file naming script engine. This is on a Windows OS.

      As you can see in the attached screenshot, entering “C:/” gets interpreted as “C:\Windows\System32/”

      I see that as wrong. The interpretation is just wrong. I have also tried to reference the source location with
      “./” but that interprets to nothing. Trying “…/” results in the source location followed by “_” (maybe two of the underscores)

      When I ran the script using nothing at the beginning of the script to try and move the files, the system moved them on its own to my “Music” folder. Since I had not tried to move the files, I would have thought Picard would have just left them where they were and worked from that folder as the base location.

          [PICARD-2612] Unexpected results in File Naming Script

          This is what happens in some cases, yes. But actually I cannot reproduce a proper issue with this. What I wrote above that it should not be possible to set an empty target dir is already the case. So the only issue I could reproduce was that clearing the target dir in option and then looking at the file naming preview can show such results. But you won't be able to save these settings this way. So unless you explicitly set "C:\Windows\System32" as a target Picard won't by itself accidentally try to move files there. And if you'd configure it as the target the only result would likely be permission errors, unless maybe you run Picard as admin and it would really move files there.

          Philipp Wolfer added a comment - This is what happens in some cases, yes. But actually I cannot reproduce a proper issue with this. What I wrote above that it should not be possible to set an empty target dir is already the case. So the only issue I could reproduce was that clearing the target dir in option and then looking at the file naming preview can show such results. But you won't be able to save these settings this way. So unless you explicitly set "C:\Windows\System32" as a target Picard won't by itself accidentally try to move files there. And if you'd configure it as the target the only result would likely be permission errors, unless maybe you run Picard as admin and it would really move files there.

          Sophist added a comment -

          Most likely is that the current directory when the Picard executable is launched is C:\Windows\System32.

          Sophist added a comment - Most likely is that the current directory when the Picard executable is launched is C:\Windows\System32.

          Sorry, slammed at work. I will get you more detail to you shortly.

          DarkOverLordII added a comment - Sorry, slammed at work. I will get you more detail to you shortly.

          The actual bug here is that an empty destination directory leads to C:\Windows\System32\ being used as the root. That definitely makes no sense. On non-windows systems it's the users home folder instead, which makes a bit more sense.

          What we should actually do I think is to make the destination directory mandatory and verify it exists if move files is activated. It doesn't make sense to enable this option without setting an actual target.

          Philipp Wolfer added a comment - The actual bug here is that an empty destination directory leads to C:\Windows\System32\ being used as the root. That definitely makes no sense. On non-windows systems it's the users home folder instead, which makes a bit more sense. What we should actually do I think is to make the destination directory mandatory and verify it exists if move files is activated. It doesn't make sense to enable this option without setting an actual target.

          Philipp Wolfer added a comment - - edited

          Can you explain in more detail what your use case is and why the destination directory doe s not work for you?

          The ability to just have the files be placer at their current source comes up from time to time but so far nobody could explain how this actually is supposed to work in practice. If you just use the existing file location and create folders there you end up with a deeper and deeper directory structure on repeated saves.

          That's not what is expected usually. There is usually some kind of folder the user considers the root. But how to decide for a file placed in c:\a\b\c\file.mp3 which folder is that root?

           

          Philipp Wolfer added a comment - - edited Can you explain in more detail what your use case is and why the destination directory doe s not work for you? The ability to just have the files be placer at their current source comes up from time to time but so far nobody could explain how this actually is supposed to work in practice. If you just use the existing file location and create folders there you end up with a deeper and deeper directory structure on repeated saves. That's not what is expected usually. There is usually some kind of folder the user considers the root. But how to decide for a file placed in c:\a\b\c\file.mp3 which folder is that root?  

          DarkOverLordII added a comment - - edited

          Would it be possible to add an option of "Same as source" in the section for Destination directory?

          That way no matter where the file was loaded from, rename is done it is done relative to where the file is currently located.

          The other option would be to allow the pathing all to be done in the scripting section thereby removing the need for the "Destination directory" option.

          DarkOverLordII added a comment - - edited Would it be possible to add an option of "Same as source" in the section for Destination directory? That way no matter where the file was loaded from, rename is done it is done relative to where the file is currently located. The other option would be to allow the pathing all to be done in the scripting section thereby removing the need for the "Destination directory" option.

          Quite possible that absolute paths are not supported here, either in general or on Windows. I'll investigate this and see what would be needed to support this.

          But the file naming script in general is supposed to be relative to the base folder configured in Options > File naming. In your case you would set it to C:\data and have the file naming script be relative to this.

          Philipp Wolfer added a comment - Quite possible that absolute paths are not supported here, either in general or on Windows. I'll investigate this and see what would be needed to support this. But the file naming script in general is supposed to be relative to the base folder configured in Options > File naming. In your case you would set it to C:\data and have the file naming script be relative to this.

            Unassigned Unassigned
            DarkOverLordII DarkOverLordII
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:

                Version Package