Forbidden File Names?
-
Today, a tester reported that they were unable to launch a couple of newer executables from one of our desktop apps. By 'unable to launch' I mean that instead of the called executable starting, it was opening a web browser stating that it couldn't find the file. (also some wonderful advice about possible mispelling and refresh) Every other executable in the menu worked correctly. :confused: My first thought was, 'silly tester, it works on my machine!' :laugh: My next thought was, security/av interference? Nope, they start on a double-click. It's only a problem when started as a process. So, two exe's that were failing to launch have one thing in common...the first part of the name which happens to be 'Mosaic'. :confused: I changed the first letter in the filename, adjusted the calling app accordingly and sure enough, it worked. :omg: :wtf: This just happened, so I'm still trying to figure out what exactly is going on. My guess is that 'Mosaic' in the filename is triggering a browser add-on to fire. I have customers using one of these 'modules' (the other is new) and have not had issues like this, though I don't know for sure if they were using the same OS environment as my tester. (Win11 w/latest patches) I don't have a Win11 system around (still on Win10) so I can't verify if this is a new behavior by design. :confused: Googling on the key terms isn't yielding anything useful. :sigh: I'm already considering what it will take to change a filename that's been in production for a few years and installed on at least a dozen customer systems. Sure, I've got a process for it, but it's not fun. X| Edit: I've just had the same behaviour confirmed on another colleague's Win11 system. 'They hate cans!' :wtf: (or just files starting with the letters mosaic! Damnit! :mad: Edit 2: After hands-on experimentation on my wife's Win11 laptop, I can confirm that there is an issue using ShellExecute to launch an executable with a filename starting with 'mosaic'. Doing so incorrectly starts a web browser with the message 'Hmmm, I can't find that file...Typo?'. :confused: It only happens on Win11 which is just now starting to be adopted by my users. Definitely weird.
"Go forth into the source" - Neal Morse "Hope is contagious"
-
kmoorevs wrote:
So, two exe's that were failing to launch have one thing in common...the first part of the name which happens to be 'Mosaic'. :confused:
Theere's a list of exceptions in Windows for some executables; famously some sim that would not work in W95. ..but no. Just naming it won't trigger that.
kmoorevs wrote:
I'm already considering what it will take to change a filename that's been in production for a few years and installed on at least a dozen customer systems
To a developer, that costs no time. If it is that expensive to you, then hire a developer. Let me say that again; you're not fit for your position by your own words.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
First, thank you for your constructive input! I really appreciate it! :)
Eddy Vluggen wrote:
..but no. Just naming it won't trigger that.
and yet, it does...consistently. Changing the filename changes the behavior. Second, regarding changing a filename, I never said it was expensive however to a developer (me) it does cost time and requires some planning to make it a seamless transition for my customers. Third, your unfounded insult means nothing to me. My colleagues and paying clients would disagree with you. :) Fourth, I might be hiring for a jr. position. Are you available?
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Today, a tester reported that they were unable to launch a couple of newer executables from one of our desktop apps. By 'unable to launch' I mean that instead of the called executable starting, it was opening a web browser stating that it couldn't find the file. (also some wonderful advice about possible mispelling and refresh) Every other executable in the menu worked correctly. :confused: My first thought was, 'silly tester, it works on my machine!' :laugh: My next thought was, security/av interference? Nope, they start on a double-click. It's only a problem when started as a process. So, two exe's that were failing to launch have one thing in common...the first part of the name which happens to be 'Mosaic'. :confused: I changed the first letter in the filename, adjusted the calling app accordingly and sure enough, it worked. :omg: :wtf: This just happened, so I'm still trying to figure out what exactly is going on. My guess is that 'Mosaic' in the filename is triggering a browser add-on to fire. I have customers using one of these 'modules' (the other is new) and have not had issues like this, though I don't know for sure if they were using the same OS environment as my tester. (Win11 w/latest patches) I don't have a Win11 system around (still on Win10) so I can't verify if this is a new behavior by design. :confused: Googling on the key terms isn't yielding anything useful. :sigh: I'm already considering what it will take to change a filename that's been in production for a few years and installed on at least a dozen customer systems. Sure, I've got a process for it, but it's not fun. X| Edit: I've just had the same behaviour confirmed on another colleague's Win11 system. 'They hate cans!' :wtf: (or just files starting with the letters mosaic! Damnit! :mad: Edit 2: After hands-on experimentation on my wife's Win11 laptop, I can confirm that there is an issue using ShellExecute to launch an executable with a filename starting with 'mosaic'. Doing so incorrectly starts a web browser with the message 'Hmmm, I can't find that file...Typo?'. :confused: It only happens on Win11 which is just now starting to be adopted by my users. Definitely weird.
"Go forth into the source" - Neal Morse "Hope is contagious"
Could it be that Windows is looking for the name of the executable for reasons of competing browsers? You start the Mosaic browser and it intercepts that launch and shows you the "wonderful world" of IE/Edge. Granted, Mosaic is about as old as the dirt the internet is made of, so...
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
Could it be that Windows is looking for the name of the executable for reasons of competing browsers? You start the Mosaic browser and it intercepts that launch and shows you the "wonderful world" of IE/Edge. Granted, Mosaic is about as old as the dirt the internet is made of, so...
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakI suspect it's an app execution alias. These are used in Windows 10 and 11. For example, on Win 11, shell-executing "python" will launch the windows store on a default install. These can be turned off in Apps & Features on the target machine. Did you try shell executing the full path to the executable (rather than just the filename)?
Gee
-
Could it be that Windows is looking for the name of the executable for reasons of competing browsers? You start the Mosaic browser and it intercepts that launch and shows you the "wonderful world" of IE/Edge. Granted, Mosaic is about as old as the dirt the internet is made of, so...
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakIt's as good a guess as I've been able to come up with! :thumbsup: I haven't ruled out Cortana intercepting the call and redirecting it to where it thinks (based on the filename?) it needs to go...only to find the callee doesn't live there! As you mentioned, the term 'Mosaic' has been around for a long time in the www lexicon, so I can sorta see a vague connection. For now, it's a good catch by my tester. I have already adapted (given in) and getting past it. I really only posted here for posterity...on the off-chance that Google may provide it to the next poor sod who can't understand why something (a core win32 method ffs) that has worked for 20 years, suddenly fails on a new Windows version. Note to my future self: As crazy as it sounds, try changing the filename. :laugh:
"Go forth into the source" - Neal Morse "Hope is contagious"
-
I suspect it's an app execution alias. These are used in Windows 10 and 11. For example, on Win 11, shell-executing "python" will launch the windows store on a default install. These can be turned off in Apps & Features on the target machine. Did you try shell executing the full path to the executable (rather than just the filename)?
Gee
Gee. wrote:
Did you try shell executing the full path to the executable (rather than just the filename)?
I was/am setting the working directory in the method calls. That could be a clue though, so thanks! :)
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Gee. wrote:
Did you try shell executing the full path to the executable (rather than just the filename)?
I was/am setting the working directory in the method calls. That could be a clue though, so thanks! :)
"Go forth into the source" - Neal Morse "Hope is contagious"
Changing CWD can be a pain in the neck (or maybe even lower down). Even seasoned programmers may believe that they change CWD, complaining that it fails. That is because the way they do it causes a new process to be spun off, and the CWD applies to that process. When it terminates, "Task completed", the changed WD dies with that process. Make sure that the process executing the CWD is not a child process. If you call some API with a CWD parameter, it might start a new process and use the parameter to set the CWD for that process, without affecting the CWD of the calling process. You have the same situation with the PATH value: A child process cannot modify the path of its ancestor process. It could change the user profile to change the initial PATH for shells started at a later time, but the shell reads the user profile at startup, and is not affected by profile updates while it is running. The same goes for arbitrarily named environment variables. Most build systems structure a build in a series of job steps, usually with each job step run as a separate process. Countless developers have tried to modify the environment (CWD, PATH or other environment variables) in one job step, expecting the modification to apply to later steps. It fails, even if the the first step updates the user profile. True enough: The next job step process is started after the profile update, but it is (in several build systems, maybe all) a plain child process, not a shell, so it inherits the environment of the build system process that creates it. The user profile is read by the shell when initializing, not at a plain process creation. In my last job, we had a large crowd of very qualified system developers. Yet, I had to explain again and again why their CWD, PATH and environment updates "failed". I urged them to forget about inheriting the environment by child processes, and rather transfer such values through the Registry, but two thirds of the SW development group were Linux developers by heart, having been forced to accept working under Windows to get a job, bluntly refusing to use any Windows mechanism unknown in Linux if there was any way to avoid it. As long as they could bitch at lengths about the worthless environment handling in Windows, not realizing that a Linux build system would behave in exactly the same way. So: When you think that you have set the WD of a given process, check it out to be 100% sure: After modifying it, retrieve the CWD to a variable you can inspect in a debugger, or print it o
-
Today, a tester reported that they were unable to launch a couple of newer executables from one of our desktop apps. By 'unable to launch' I mean that instead of the called executable starting, it was opening a web browser stating that it couldn't find the file. (also some wonderful advice about possible mispelling and refresh) Every other executable in the menu worked correctly. :confused: My first thought was, 'silly tester, it works on my machine!' :laugh: My next thought was, security/av interference? Nope, they start on a double-click. It's only a problem when started as a process. So, two exe's that were failing to launch have one thing in common...the first part of the name which happens to be 'Mosaic'. :confused: I changed the first letter in the filename, adjusted the calling app accordingly and sure enough, it worked. :omg: :wtf: This just happened, so I'm still trying to figure out what exactly is going on. My guess is that 'Mosaic' in the filename is triggering a browser add-on to fire. I have customers using one of these 'modules' (the other is new) and have not had issues like this, though I don't know for sure if they were using the same OS environment as my tester. (Win11 w/latest patches) I don't have a Win11 system around (still on Win10) so I can't verify if this is a new behavior by design. :confused: Googling on the key terms isn't yielding anything useful. :sigh: I'm already considering what it will take to change a filename that's been in production for a few years and installed on at least a dozen customer systems. Sure, I've got a process for it, but it's not fun. X| Edit: I've just had the same behaviour confirmed on another colleague's Win11 system. 'They hate cans!' :wtf: (or just files starting with the letters mosaic! Damnit! :mad: Edit 2: After hands-on experimentation on my wife's Win11 laptop, I can confirm that there is an issue using ShellExecute to launch an executable with a filename starting with 'mosaic'. Doing so incorrectly starts a web browser with the message 'Hmmm, I can't find that file...Typo?'. :confused: It only happens on Win11 which is just now starting to be adopted by my users. Definitely weird.
"Go forth into the source" - Neal Morse "Hope is contagious"
My freshman year at the Tech. University was the last year of two huge Univac 1100 mainframes as the primary computers for student exercises. Those who have ever worked with the EXEC-8 OS will remember that the file system had "files", which were fairly large disk areas that you organized in "elements" which were e.g. source program units (i.e. what we call "files" in other systems). Usually, students were given a single such "file" to hold all their work, customary named by the student's name. One of my classmates were refused: Her name was not accepted as a file name, and we could not see the reason. We asked the system managers, who explained that Exec-8 used a Master File Directory organized as a hash table on the complete file "path" (not a hierarchical one, but a concatenation of a project name and the file name. The code doing the hashing could not handle bucket overflow. So the rejection of my classmate's name really was "Sorry, this hash bucket is full - please select a file name hashing to another bucket!"
-
Today, a tester reported that they were unable to launch a couple of newer executables from one of our desktop apps. By 'unable to launch' I mean that instead of the called executable starting, it was opening a web browser stating that it couldn't find the file. (also some wonderful advice about possible mispelling and refresh) Every other executable in the menu worked correctly. :confused: My first thought was, 'silly tester, it works on my machine!' :laugh: My next thought was, security/av interference? Nope, they start on a double-click. It's only a problem when started as a process. So, two exe's that were failing to launch have one thing in common...the first part of the name which happens to be 'Mosaic'. :confused: I changed the first letter in the filename, adjusted the calling app accordingly and sure enough, it worked. :omg: :wtf: This just happened, so I'm still trying to figure out what exactly is going on. My guess is that 'Mosaic' in the filename is triggering a browser add-on to fire. I have customers using one of these 'modules' (the other is new) and have not had issues like this, though I don't know for sure if they were using the same OS environment as my tester. (Win11 w/latest patches) I don't have a Win11 system around (still on Win10) so I can't verify if this is a new behavior by design. :confused: Googling on the key terms isn't yielding anything useful. :sigh: I'm already considering what it will take to change a filename that's been in production for a few years and installed on at least a dozen customer systems. Sure, I've got a process for it, but it's not fun. X| Edit: I've just had the same behaviour confirmed on another colleague's Win11 system. 'They hate cans!' :wtf: (or just files starting with the letters mosaic! Damnit! :mad: Edit 2: After hands-on experimentation on my wife's Win11 laptop, I can confirm that there is an issue using ShellExecute to launch an executable with a filename starting with 'mosaic'. Doing so incorrectly starts a web browser with the message 'Hmmm, I can't find that file...Typo?'. :confused: It only happens on Win11 which is just now starting to be adopted by my users. Definitely weird.
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Today, a tester reported that they were unable to launch a couple of newer executables from one of our desktop apps. By 'unable to launch' I mean that instead of the called executable starting, it was opening a web browser stating that it couldn't find the file. (also some wonderful advice about possible mispelling and refresh) Every other executable in the menu worked correctly. :confused: My first thought was, 'silly tester, it works on my machine!' :laugh: My next thought was, security/av interference? Nope, they start on a double-click. It's only a problem when started as a process. So, two exe's that were failing to launch have one thing in common...the first part of the name which happens to be 'Mosaic'. :confused: I changed the first letter in the filename, adjusted the calling app accordingly and sure enough, it worked. :omg: :wtf: This just happened, so I'm still trying to figure out what exactly is going on. My guess is that 'Mosaic' in the filename is triggering a browser add-on to fire. I have customers using one of these 'modules' (the other is new) and have not had issues like this, though I don't know for sure if they were using the same OS environment as my tester. (Win11 w/latest patches) I don't have a Win11 system around (still on Win10) so I can't verify if this is a new behavior by design. :confused: Googling on the key terms isn't yielding anything useful. :sigh: I'm already considering what it will take to change a filename that's been in production for a few years and installed on at least a dozen customer systems. Sure, I've got a process for it, but it's not fun. X| Edit: I've just had the same behaviour confirmed on another colleague's Win11 system. 'They hate cans!' :wtf: (or just files starting with the letters mosaic! Damnit! :mad: Edit 2: After hands-on experimentation on my wife's Win11 laptop, I can confirm that there is an issue using ShellExecute to launch an executable with a filename starting with 'mosaic'. Doing so incorrectly starts a web browser with the message 'Hmmm, I can't find that file...Typo?'. :confused: It only happens on Win11 which is just now starting to be adopted by my users. Definitely weird.
"Go forth into the source" - Neal Morse "Hope is contagious"
-
If I ever have the time to investigate this further, I can give it a shot, however I found it easier to take the path of least resistance which was renaming the offending executables and getting on with more important items. (I gave in!) :sigh: The whole thing is still a mystery to me. :confused: I'll be getting a Win11 development system in the next few months which may shed some light on things. Thanks for the suggestion! :thumbsup:
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Today, a tester reported that they were unable to launch a couple of newer executables from one of our desktop apps. By 'unable to launch' I mean that instead of the called executable starting, it was opening a web browser stating that it couldn't find the file. (also some wonderful advice about possible mispelling and refresh) Every other executable in the menu worked correctly. :confused: My first thought was, 'silly tester, it works on my machine!' :laugh: My next thought was, security/av interference? Nope, they start on a double-click. It's only a problem when started as a process. So, two exe's that were failing to launch have one thing in common...the first part of the name which happens to be 'Mosaic'. :confused: I changed the first letter in the filename, adjusted the calling app accordingly and sure enough, it worked. :omg: :wtf: This just happened, so I'm still trying to figure out what exactly is going on. My guess is that 'Mosaic' in the filename is triggering a browser add-on to fire. I have customers using one of these 'modules' (the other is new) and have not had issues like this, though I don't know for sure if they were using the same OS environment as my tester. (Win11 w/latest patches) I don't have a Win11 system around (still on Win10) so I can't verify if this is a new behavior by design. :confused: Googling on the key terms isn't yielding anything useful. :sigh: I'm already considering what it will take to change a filename that's been in production for a few years and installed on at least a dozen customer systems. Sure, I've got a process for it, but it's not fun. X| Edit: I've just had the same behaviour confirmed on another colleague's Win11 system. 'They hate cans!' :wtf: (or just files starting with the letters mosaic! Damnit! :mad: Edit 2: After hands-on experimentation on my wife's Win11 laptop, I can confirm that there is an issue using ShellExecute to launch an executable with a filename starting with 'mosaic'. Doing so incorrectly starts a web browser with the message 'Hmmm, I can't find that file...Typo?'. :confused: It only happens on Win11 which is just now starting to be adopted by my users. Definitely weird.
"Go forth into the source" - Neal Morse "Hope is contagious"
kmoorevs wrote:
Doing so incorrectly starts a web browser with the message 'Hmmm, I can't find that file...Typo?'.
Mosaic is the name of a web browser from the mid 1990s. Years later Mosaic became Netscape and then later became Mozilla Firefox. It would appear that Windows still has a few VERY OLD bits of code lurking around.