System details: Windows7-SP1x64 + Tweaking Registry Backup v3.3.1
This thread is the end result of a complex and confusing investigation documented in this thread:
http://www.tweaking.com/forums/index.php/topic,3830.0.htmlTo simplify things I am starting this new thread containing just the new issue I have identified
I have posted a note on the old thread pointing to this thread - I trust that is not breaking the Forum rules
I am reporting a problem that results from the difference in the behaviour between:
Running a registry restore from within the Registry Backup program
Running a registry restore from the Recovery Console Microsoft state that Copying a file causes the destination file to be allocated a new set of Security Permissions
- which it inherits from the new parent folder
- whereas if you Move a file (within the same volume) it retains its original Security Permissions.
Therefore using a Copy command to restore registry files should reinstate the original (and correct) Inherited Security Permissions to the copied files automatically - regardless of the permissions visible on the backup versions.
However when restoring registry files with Tweaking Registry Backup something odd is happening. When Restoring the registry from within the Tweaking Registry Backup program:The restored registry files have slightly different Security Permissions than the originals
These restored files ONLY show <not inherited> Security Permissions
- they have not obtained the expected Inherited permissions of the parent folder
- they do NOT have an explicitly named "current user - Full Control" permissions entry
When Restoring the registry using "dos_restore.cmd" from the Windows Recovery Console: The restored files ONLY show inherited Security Permissions obtained from the new parent folder
- this is what is expected for files that have been Copied to a new folder
The restored files have the correct Security Permissions - including "current user - Full Control" permissions entry
This difference in Security Permissions on the restored files appears to cause no problems - except for the one situation I encountered (there may of course be others). I discovered that Win7 refuses to load the UsrClass.dat (at account logon) when the Security Permissions do not include the "current user - Full Control" permissions entry. Full analysis of this problem is documented in my original thread:
http://www.tweaking.com/forums/index.php/topic,3830.0.htmlThis failure to load UsrClass.dat is not immediately apparent to the user - but appears in the Application Event Log (Event ID 1542 with a Red Error Flag). However several GUI customizations are lost due to this failure to load - most notably the Customize Notification Area Icons no longer preserves changes over a reboot - and this is only rectified once the "current user - Full Control" permissions entry is reinstated on the UsrClass.dat file.
It is unclear why Win7 refuses to load UsrClass.dat as the Effective Permissions check shows Full Control for the current user, SYSTEM and the Administrators group - there appears to be a "bug" in the Win7 account login code. However the odd behaviour of the Restore from within the Registry Backup program might cause other issues in the future if not corrected.
Copied files should automatically gain Inherited permissions from the destination parent folder
- odd things can happen when files do not have the expected permissions for the folder where they reside.
UPDATE:If the Restore (from within the program) is being processed in two stages this could explain the difference in permissions.
Where a file is initially Copied to a temporary folder and then Moved to its final location it will retain the permissions of the temporary folder.
Doug Collins - Computer Support Engineer - London UK
