Renaming 'mp3tagv329-x64-setup.exe' to 'mp3tag.exe' causes an incomplete installation

Support
1

I stumbled upon some interesting behaviour with the 'mp3tagv329-x64-setup.exe' installation package. I'm not sure if this is a bug, or intended/expected behaviour. I can reproduce the behaviour on multiple machines.

Overview:

I have mixed machines in my environment - Windows 10 & 11, as well as an RDS server running Windows Server 2022. The 64-bit installer behaves the same way on all versions of Windows when it is renamed to 'mp3tag.exe'.

Behavour:

Once the package is renamed to 'mp3tag.exe' and it is run, it launches normally. The usual installation screens appear after clicking 'next' on each screen. I leave the install location set for the default (C:\Program Files\Mp3tag). After clicking the 'install' button, the Mp3tag installation begins, and the file copy window is displayed. However, the progress bar doesn't advance, and after a few moments, the installation simply ends - the screen closes uncerimoniously. There are no errors & no windows - absolutely nothing. When I navigate to C:\Program Files, the Mp3tag folder has been created, but no files are copied. If I check what's installed on my computer, I see that Mp3tag has not been installed. If I was attempting to update a previous installation, I will see that the old version remains.

If I rename the mp3tagv329-x64-setup.exe package to anything other than mp3tag.exe, the installer runs & completes as expected. The final screen is displayed where I can click "Finish' and all is well.

How I discovered this/why I renamed the installation package:

I have multiple computers, and I push out the installation to several computers all at once via a script. I rename installation packages to something generic so that I don't have to modify my script each & every time I download an update. My script was working for quite a while, until I noticed the machines I pushed the update to weren't actually updating. That led me to troubleshoot, and naturally, I suspected something wrong somewhere with my script, or Windows. When I exhausted those possibilities, I then simply attempted to run my renamed 'mp3tag.exe' package manually by double-clicking, and it was then that I noticed the odd behaviour. I haven't encountered this issue with any other installation package - I have a bunch of programs that I push to my computers when updates are released.

The problem is easily resolved by choosing a different generic name. I realize I named the package the same as the actual executable for the program itself, but I haven't had this issue with other installation packages - just Mp3tag.

This isn't critical, and likely very few people will ever encounter the issue. However, I thought I would mention it. I'm not sure if the same happens with the 32-bit installer (I don't use it), but I suspect the same problem might exist.

I don't require support for this - just reporting some interesting behaviour.

2

Just a wild guess:
The installer is looking for a running (or installed) mp3tag.exe
In your situation, the renamed mp3tag.exe installer has the same name as the executable program itself.
So the installer tries to close "itself" in your case?

Does this work with other software if you rename the installer to the executable name?

3

Yes, other installers do function properly if I change the package name to match the actual program name. For example, if you download WinRar & rename it's package to winrar.exe, it'll install & function as expected.

Another example - I just tried renaming the Notepad++ installation package to notepad++.exe - it will run & install normally.

There's obviously something a bit different with the Mp3tag installer where I can't use the same name as the program.

You mentioned closing itself - and likely the routine is trying to copy itself to the install location. Naturally, it can't because it's already opened, and then just ends without copying the actual files to where they need to live.

4

Since version 3.29 (and some beta-versions before) MP3tag has a new feature to close itself when it is already running. Before that it just asked you to close it yourself manually.

If you rename the installer to mp3tag.exe it will notice that there is a process with the name "mp3tag.exe" already running and closes it.
Starting older renamed installers would ask you to close Mp3tag, even if it was not running.

1 question:
Is there a reason to rename an installer? If you do that, you will no longer be able to distinguish between different installer versions and will also not be able to tell whether it is the program or the program's installer without looking in the details.

5

Thanks for your detailed response - it makes sense.

The answer to your question appears under the section "How I discovered this/why I renamed the installation package:" in my initial post. You may refer back to that explanation for complete details.

I will simply use a different name going forward. Based on my scripts and the tools I use, I already know the version number of the package without needing to look at the name of the file.