REG file not working even with success message

[britechguy]

I sometimes create registry editing (REG) script files, particularly for blind or visually impaired clients where a registry edit that would be very likely to have "fat fingering" occur is involved. Someone wanted to have the default attachment save directory for Outlook 2016 changed, so I threw together this three liner:
---------------------
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Options]
"DefaultPath"=C:\Users\Public\Documents\BriTechGuy\OutlookAttachments
---------------------

The HKCU entry definitely does exist, all the way down to "Options" prior to this REG file being run. I have tried the value after the equal sign both enclosed in double quotes and plain, as above. In either case, after running the file and OK-ing it when Registry Editor asks if I really want to allow the file to make changes, the final message is that the keys have been successfully added.

The problem is, they're not. I have never had a success message show up that was spurious. I have done a find command from the root level of the Registry for the key DefaultPath and it is not found anywhere. I thought it might have somehow been "misplaced," as unlikely as that was, but it's nowhere to be found.

Any theories as to why this is happening (or I should say, not happening, as the key is not created) as well as how to fix it would be appreciated.

Windows 10 Pro, Version 21H2, Build 19044.1586

 

[nlinecomputers]

Manually create the key with regedit then export the key.

 

[phaZed]

Try this:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Options]
"DefaultPath"="C:\\Users\\Public\\Documents\\BriTechGuy\\OutlookAttachments"

 

[britechguy]

@phaZed, thanks. I had no idea that the double backslashes were necessary.

@nlinecomputers, this is what is the result of an export of the DefaultPath key if I create it by hand and paste in the folder path previously noted. I see that the double backslashes are what comes out even if that's not what's shown in regedit itself
-----
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Options\DefaultPath]
@="C:\\Users\\Public\\Documents\\BriTechGuy\\OutlookAttachments"
-----

Screenshot from regedit:

 

[phaZed]

Ya, it's an escape character, so it takes the slashes as literal. So if you needed to have quotes in a string - @="\"My String in Quotes\""

"My String in Quotes" would be stored in the variable as opposed to My String in Quotes

So, in essence, you were passing it @="C:UsersPublicDocumentsBriTechGuyOutlookAttachments" which should give an error not found. I wonder if the "success message" was an "ok, we're done processing" as opposed to "successfully added with 0 errors". You only need to do this with strings encapsulated in quotations.

 

[britechguy]

@phaZed

What follows is not meant to sound snarky, though it probably will. I am aware of what an escape character is, but I don't recall ever having used one inside a string literal in Windows before, which is what threw me on this one.

I'm somewhat of a regular expression wiz and heaven knows I'm escaping things left and right in some of the more complex concoctions of those.

Whether I had the string enclosed in double quotes or not, the same success message was produced that the keys in the file had been successfully added to the registry. I agree with you that what it likely really means is that regedit run with the REG file did not bomb out and finished with a non-error code.

I seldom enclose a string in quotes unless I know it contains whitespace. At one time, I would never have even thought about doing that for a folder path, but now since whitespace is permitted in those paths you have to.

Your observation and @nlinecomputers' suggestions both aided in solving the mystery. This little tidbit will stick, that's for sure!

 

[britechguy]

Well, another interesting discovery, this does not work even with the properly escaped path if I use the version where the key is specified within double quotes followed by the equal sign followed by the string.

It is only working if I use the format that gets generated via the registry export command, where the new key is specified on the line with the square brackets and the actual value after a line starting with "@=".

Very, very weird as far as I'm concerned. And I still get the success message when there's been no success with the "DefaultPath"= style.

 

[phaZed]

That is weird! Permission issue on the key or inherited permissions? Or I wonder if an AV is blocking Reg edits or perhaps Outlook has the key locked or something like that.

 

[britechguy]

I'm really not sure what was up. But I can say this, as I now have this working. The documentation out there all seems to pretty directly imply that the DefaultPath should be a key beneath the Options key, but that doesn't work. It is a value that is associated with the Option key itself. And it could be that I was looking in the wrong spot, too, as I was expecting it to show up as a subkey/child key under Options in the regedit tree view, but it doesn't (or at least the setup that gets Outlook to use an alternate folder for the save all attachments action). It's over there in the list of values associated with the Options key itself.

This was the (very simple) REG file that got the desired result: BriTechChangeDefault_Save_Path.REG

I have the feeling that one of my earlier versions would have worked, too, but I was thinking I should see a separate "folder" in the registry tree for DefaultPath, and you don't and shouldn't.

I've verified with Outlook 2016 that the registry change this file makes does make Outlook do a save all attachments to the specified folder.