[SOLVED] Registry Backup RB v3.4.1 from within WR AIO v3.8.5 - what is sddl.txt?

[Still_Game]

 Just run an auto Shadow Copy of my Windows 7 notebook via Registry Backup v3.4.1 from within WRAIO v3.8.5 and noticed a text file called sddl.txt in the created backup set which I haven't noticed in previous backups. Can anybody tell me what it is?

Thanks.....

[Julian]

after opening that file I believe that would be the permissions for those particular keys i can ask shane to make sure but that is what it looks like to me. 

[Still_Game]

Thanks, Julian, I assumed it might be something like that but it goes way beyond my competence level. I was just concerned in case it contained some error codes or similar that I couldn't spot.

[Julian]

No problem i'm still going to ask Shane to make sure because it really looks like something ManageACL would make.
Shane used to use SetACL (https://helgeklein.com/setacl/)
until he finally gave up on the error's it was causing. So he spent days programming and made his version of SetACL and called it ManageACL. He had to teach himself C++
and ManageACL is pretty awesome with setting permissions it improved the repair speeds of any repairs that involved permission's.

[Dougcuk]

Registry Backup v3.4 implemented a new feature - to backup (and restore) the security permissions of the registry files.
These permissions are (as you stated) saved in the SDDL.txt file - and re-applied during restoration of the registry files.

This new feature was introduced to prevent issues where Windows baulked at accessing the restored registry files due to "incorrect" security permissions. I reported a minor issue (with the user registry) under Win7 and various reports have been made about odd behaviour under Win10 - after restoration of the bare registry files. See http://www.tweaking.com/forums/index.php/topic,3865.msg27838.html#msg27838

Normally the "correct" security permissions of the registry files are inherited from the folder where they reside. These inherited permissions were not being applied to restored user registry files (system registry files were ok) - and in some cases the non-standard permissions were causing access problems for some Windows functions.

Problems only occurred when restoring from within the Registry Backup program (normal Windows start-up)   
- restoring from the Recovery Console (using the F8 Repair option) always worked correctly.
- the two restore methods use different commands to place the backup files in the correct folder locations
- the Recovery Console method triggers the default Windows behaviour to assign security permissions based on those of the parent folder.   

[Still_Game]

Thanks, Doug - I've marked the topic as solved.