I have just discovered how to resolve 50% of the problem with altered Security PermissionsI had been using the "Backup Location" as set by the Tweaking Registry Backup installer
- this was set as %WindowsDrive%\RegBackup\
- for me, as for most users, this equates to C:\RegBackup\
I had already found that ERUNT preserved the correct Security Permissions during both Backup and Restore
However for ERUNT my backup folder is located inside my Users Folder - C:\Users\Doug\ERUNT\
So as a test I changed the Backup Location (for Tweaking) to parallel the setting I use for ERUNT
- so I set it to %CurrentProfile%\RegBackup\
- which equates to C:\Users\Doug\RegBackup\
And magically this caused the backup files to retain the correct Security Permissions as per ERUNT
Thus changing the Backup Location - from C:\RegBackup\ to C:\Users\Doug\RegBackup\
solves half of the problem - the backup files now retain the original "Doug Full Control" Security Permission entry
The Security Permissions seen when using C:\Users\Doug\RegBackup\ were as follows:
SYSTEM Full Control Inherited from C:\Users\Doug\
Administrators (Group Account) Full Control Inherited from C:\Users\Doug\
Doug (Current User) Full Control Inherited from C:\Users\Doug\
The Security Permissions seen when using C:\RegBackup\ were as follows:
SYSTEM Full Control Inherited from C:\
Administrators (group account) Full Control Inherited from C:\
Users (group account) Read & Execute Inherited from C:\
So I had high hopes that when I ran a restore that the restored registry files would retain
the now correct (Inherited) Security Permissions - but sadly no.
We again end up with the incorrect "Not Inherited" versions - just as before
We end up with the following Security Permissions on the restored files:
SYSTEM Full Control Not Inherited
Administrators (group account) Full Control Not Inherited
Users (group account) Read & Execute Not Inherited
Just as before we have no Inherited Permissions and also lose the critical "Doug - Full Control" entry
- and the "Users (group account) - Read & Execute" entry is recreated
So the new question is:
Why does the Restore process fail to preserve the "correct" Security Permissions now showing on the backup files?I'm not sure of the ramifications of moving the Backup Location folder out of the root
- it suits my situation as I only use one primary user account
- but it could be complicated where you have multiple active users on the computer
- backups would no longer be in one central location but saved per user
- and as for backups scheduled at startup I'm not clear where it would attempt to save those
Any ideas about forcing the Inherited Security Permissions to be applied to the restored file?
I will leave you to ponder that one!UPDATE:Having done some research the following rules should apply:
The simple rule is that inheritable ACLs take effect only when a file is created, not when it is moved or renamed.
Copying creates a new file, which means that inheritable ACL properties of the destination folder do take effect.
However Moving a file within the same volume doesn't create a new file, therefore the ACLs remains unchanged. Note: Moving a file to another volume does create a new file, as it requires a Copy and Delete operation.
When a file is copied, none of the attributes from the original file are kept on the copy and it also gets a new owner
All gets a bit confusing - see here:
http://think-like-a-computer.com/2011/07/24/moving-files-on-the-same-ntfs-volume-does-inherit-permissions/The implication of this "Update" is that the Security Permissions visible on the backup copies of the files are not important.
When the files are copied back (restored) they should automatically obtain the correct Inherited permissions.
Therefore the location of the backup folder is not causing a problem - despite the permission differences.