@hans, yeah that’s exactly what we are talking about. I see that it works as expected for you but not for me doing a similar operation. I’ll duplicate exactly what you’re doing later today using you filename and get back to you.

Cool! 😊  -- looking forward to it.

p.s I really do believe you're not making this up!

I now see what’s wrong. It has to do with whether the extension of the custom filename is provided. The suggested name ConnectMeNow suggests always has the “.ini” extension appended to the filename in the Save As: box. When I changed from the suggested name to my custom name format I did not add the “.ini” extension which does not issue the overwrite warning and ConnectMeNow happily modifies (overwrites) the file if it exists. If I add the “.ini” extension then I do indeed receive the overwrite warning dialog. It appears ConnectMeNow assumes the “.ini” extension even when one is not provided since it writes the file with the “.ini” extension added, i.e., using just the name test generates a file called “test.ini”. However, when that’s true then it somehow bypasses the overwrote warning code if you use the same filename without an extension. I assumed ConnectMeNow would append the “.ini” extension as it appears it does by it fails to test the existence of the file apparently when no extension is provided. The same thing happens if you click on a previous saved config file in the bottom file list box, e.g., the clicked on filename is entered in the Save As: box without the “.ini” extension.

While this might not be a bug pre se I would think it needs addressing. The failure can be tested if you use your example in your video but leave off the “.ini” extension when you enter the Save As: filename, i.e., “test” instead of “test.ini”.

I hope I explained how failure mode happens and it makes sense..

Also, the spam issue I reported in the regular thread was caused by my VPN being enabled. Sorry for the false alarm..

Great find! 👍 

Looks like the standard macOS dialog at the same time honors and ignores the "default extension" setting.
It honors the extension by adding the .ini by itself, but ignores the verification - as I have no code that changes the filename.

So when I disable the default extension, by leaving it blank, then things do seem to work proper.

Note: I did notice on my Mac that the .ini extension is always added when I do set the default extension. I even have to do an effort to remove the ".ini" part.
And this is how I found what is causing this ...

In Finder -> Settings -> Advanced, I do have the "Show all filename extensions" checked

When enabled, you'll always see the .ini extension, and you will not have this problem, like seen in my video.

However things become sketchy when you disable this option - then I can reproduce the problem happening that you are running into consistently.

I'll remove the default ".ini" extension for now, so in the next release I'll include this (maybe today), and I for now will see this to be a macOS bug.

p.s. I removed your other post - as its a duplicate of this one 😉 

@Hans, wow that is a weird macOS bug for sure. Unfortunately or fortunately depending on how you look at it, seems I'm in the habit of finder such weird issues, 😆. Sorry for being such a PITA 🙄. Maybe adding the extension should be a ConnectMeNow preference setting??

To be honest. I have always had the "Show all filename extensions" preference setting disabled and have never seen this issue.

Thanks for cleaning up my other posting..

Just uploaded v4.0.18 ... give it a try 😊 

Hans, yeah that sort of works but it also exposes another issue when you save a configuration with a custom name such as "test.ini" and you go to save another configuration and use the bottom file listing part of the Save As: dialog and click on the existing "test.ini" file the Save As: box get filled in with "test" and not "test.ini" which causes a new configuration called "test" to obviously be saved which I guess is the result of the disabling of the ".ini" extension you removed(??). Maybe you just can't do anything about this new condition and I guess that's alright..

Haha, never apologize for finding bugs and following through! 😊 

For now I'll leave this "fix" as is.
I've heard of only 2 users actually using the backup feature, and both of them seem knowledgable enough to add ".ini" or not 😉 

It is an odd bug though - I agree. I always like to see my file extensions, and that's why I had not seen this before.

Feel free to report more bugs if you find them! 😊 
(no guarantees I'll fix them, but when I have time I always try to fix them)

Posted by: @hans

↑

Feel free to report more bugs if you find them! 😊 

Hans you can count on it! 😀

I do have an enhancement request wrt to the menubar icon. Would it be possible to show the same icon on the menubar that is shown for a mounted share when it’s mounted to significant that at least one of the defined shares is mounted?

When none are mounted the current icon should be shown.

I’m referring to the icon with the illuminated green status lite BTW.

BTW, thanks for the quick action on the overwrite issue. Great app and great support!!

Thanks Walt! 😊 
I do what I can, when I can -- it is still a hobby. And it always feels good to help when I can.

As for your feature request; I'll take that in consideration as an option for users to set.
i'll have to think about this a little more, like this being an option where shares can be included or excluded, or something like that.
Added it to the feature requests though! I can see this could be useful if done right 😊