Main Forum > Tweaking.com Support & Help
Event ID 1542 - Customize Notification Area Icons fault - Win7
Shane:
CopyFileex API is used
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx
--- Quote ---Windows 7, Windows Server 2008 R2, Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP: Security resource attributes (ATTRIBUTE_SECURITY_INFORMATION) for the existing file are not copied to the new file until Windows 8 and Windows Server 2012.
The security resource properties (ATTRIBUTE_SECURITY_INFORMATION) for the existing file are copied to the new file.
--- End quote ---
The program doesnt set the ATTRIBUTE_SECURITY_INFORMATION flag, didnt even realize it had that flag lol.
So I will set that flag on it, but I still think the best option is to start backing up the permissions with it (To a separate file with the permission info) and then when it is restored the program will set the permissions back using my ManageAcl tool.
The reason I like this is because if the backup folder ever had its permissions changed then it would change the backup files as well and so restoring would still have the same problem or worse if the permissions where copied with it, then got changed by something and then restored with those permissions and they where set to deny or something.
So to keep something like that from happening I can backup the permissions info to a text file and restore them. So far that is my plan, that way the permissions stay proper on the files AND it covers if the permissions ever get changed by another program or user in the backup itself. :wink:
Shane
Dougcuk:
Well it's your choice - re backing up the permissions - just seems to be solving a problem that doesn't really exist
- but your solution will obviously work.
The ONLY problem step we have is MOVING the files from a non-user TEMP folder which transfers the wrong permissions.
And as I pointed out the restore from the Recovery Console and ERUNT both work perfectly
- both making use of the default inherited permissions behaviour of Windows.
With my solution any "messed up" permissions on the backup versions wouldn't be an issue
- as these would get reset when the files are Copied to the Users TEMP folder
With your solution my only worry would be that if someone messed up file permissions
and then did a backup then these incorrect permissions would be perpetuated
as the permissions would never be reset to the correct defaults.
Neither solution can protect from all possible "self inflicted " permissions screwups.
Just a couple of closing notes:
The COPY command was designed NOT to set attributes - that has always been its default behaviour.
The copied files collected their inherited permissions from the destination folder.
Re the documentation for the CopyFileEx ATTRIBUTE_SECURITY_INFORMATION flag
- it appears to say that this flag is not available in Win7 only for later Windows versions
- so you would need workarounds for XP, Vista and Win7 if you started to rely on that.
Shane:
No matter on what i decide to do on the update for it all i know is I havent looked at the restore code since I first made it, so I think it will be time to relook over all of it and see if I can find any better way of doing things.
This might explain why erunt defaulted to backing up the registry to the Windows folder.
The big problem is how the APIs in Windows can be a pain in the butt. One APi may do the job but it doesnt doing something that is needed, or you find another APi to do it but it is only supported in newer versions. Then there is the APIs that work fine but where removed in newer versions of Windows.
Big pain in the butt. But when I made the restore it was before Windows 8 and was aimed XP and 7. So time to see what new APIs I can use and just have to put in code to use the different APIs for the different version of Windows. That and also backing up the permissions. I think I may end up going with a combo type of fix lol
Shane
Dougcuk:
Well it seems you have your heart set on backing-up the permissions data
- I will view it as another extra feature over and above what ERUNT can do.
But I was curious as to how ERUNT manages to restore the User registry files successfully
- with all the correct permissions, and independent of the backup folder location
- initiated from within Windows, without any extra data.
I know ERUNT can do this trick with the User registry files up to and including Win8
- and it only uses the API's that were available in Windows XP (2005)
Tests show that ERUNT copies the User registry files in one step BEFORE the reboot
- it doesn't make use of any TEMP folder when restoring the User registry files
- the existing "live" files are copied to .bak versions alongside the originals
- the selected backup versions are Copied over the existing "live" files
- all while the current user is still logged on to that user account
- you MUST then reboot (which is prompted) or the User Account can be damaged.
ERUNT must restore the User files using elevated privileges of some kind (SYSTEM?)
- to allow it to copy the two User registry files with that User account still open
- plus maybe some other trick to stop Windows overwriting the restored files at shutdown
FYI - my guide to configuring ERUNT for Win7 has been online for many years now
- posted on my server here: http://www.stargateuk.info/upload/ERUNT_Tweaks_Win7.txt
Note: The only reason ERUNT originally defaulted to backing up inside the Windows folder
was that this was the only folder location guaranteed to be accessible from the XP Repair console
In early versions of XP you had to set a registry key to unlock other folder trees during Repair.
Shane:
Erunt may be using different APIs to get the job done, I should grab the last version that was done of it and see if I can sniff out the APIs it is using and i can at least research them.
Shane
Navigation
[0] Message Index
[*] Previous page
Go to full version