Main Forum > Tweaking.com Support & Help
ACLs on UsrClass.dat messed up after restore
indrawn:
I ran chkdsk two times on C: (once with /sdcleanup and once without), and no problems were reported in the event log.
I just restored with the other utility (RegBak 1.5), and it seems to have worked fine. No classes issues at all. This is meant as info and not as a middle finger. I realize you owe me nothing.
Thanks for your time.
Shane:
I don't take it as a middle finger at all :-)
I am actually very very curious. I restore the registry with RB constantly on my test machines, from xp to 10 and never had any trouble with it loading, yet on your system we do.
So that means there is a unknown variable at play, we just need to find out what it is :-)
So lets cover all the quick stuff first.
Answer these for me, if I already asked them before I am sorry, been up going on 72 hours trying to get caught up and if it wasn't for spell check this wouldnt be working lol
1. Where do you have the registry files being backed up to? What folder path? (Goal here is to see if a odd file path might be causing a unknown bug)
2. When you used the other reg program, did it restore from the registry files that RB took or did it back up its own and restore those? (Goal here is same as the first one and knowing if the program that had success had a different backup path)
3. If the other program used its own backup, what is the folder path they are stored at? (Goal is same as #2)
4. With RB have you tried restoring backups that where done with VSS and another with fallback? (Goal here is to find out if it is the way the registry file is being saved is the cause, of course you said you could restore the files manually with no problem)
5. What are the permissions problems exactly, is it that system is the owner and so when you boot it fails and setting it to you lets it work? (Goal here is I have seen bugs where the system account doesnt have admin privileges anymore because of a corruption somewhere, adding system to the administrators groups fixes it, my Windows Repair does that before starting the repairs)
Lets go with that info first and see what direction it points us :-)
Shane
indrawn:
1. My base backup folder was "D:\Backups\Registry Backup". This is a separate HDD, with Windows running on C:. Of course, the computer name was added to that path.
2. RegBak restored its own backups, which had the same base directory, except that it doesn't (as I have it configured) add the computer name; it adds a date directory (e.g. "2015-09-18") and under that a time directory (e.g. "10;14 AM").
3. Oops, already answered that one. :)
4. No. I only ever used VSS. Too paranoid to use fallback, ever.
5. Good question. I wish I had been more specific in my first post. I had to look at my own description of the problem, which was simply: "My own user account did not have access to UsrClass.dat." I should have listed the ACLs. [SIGH] Right now my system is in what I call a "State of grace" and I'm loathe to mess with it. But this never lasts long (Microsoft sees to that). So next time I have to mess around, I will look at exactly what the issue is. Sorry I can't be more specific on this one.
I did just try something, though. I backed up my ID's UsrClass.dat using RB and RegBak, as closely as possible in time. I thought the files backed up would be identical, but they're not. I see two bytes at the very beginning of the file that differ. I retried and the same was true again. No more detail as I assume this is just because of the file being updated normally by Windows.
But another difference was that RB had no attributes for UsrClass.dat turned on, other than the "c"ompression bit. RegBak saved UsrClass.dat with "a"rchive, "h"idden, and "c"ompression. Now that I've typed that, I can't see why it would matter. :undecided:
The ACLs on both saved UsrClass.dat files are identical, though, including the owners (Administrators).
Shane:
--- Quote ---1. My base backup folder was "D:\Backups\Registry Backup". This is a separate HDD, with Windows running on C:. Of course, the computer name was added to that path.
--- End quote ---
Ok good, I ask because the Windows API is very picky about restoring the registry from another drive. So RB will copy the reg files to the windows temp folder first and have the API pull it from there.
--- Quote ---2. RegBak restored its own backups, which had the same base directory, except that it doesn't (as I have it configured) add the computer name; it adds a date directory (e.g. "2015-09-18") and under that a time directory (e.g. "10;14 AM").
--- End quote ---
Should be ok since RB copies the files to the temp folder. One thing we will have to check is if anything is messing with RB when it is copying the files.
--- Quote ---4. No. I only ever used VSS. Too paranoid to use fallback, ever.
--- End quote ---
All I use is fall back, a lot faster and never once had any trouble with it. In fact i find that things are better with it, mainly because the registry is a database. Just like any other database it gets overhead and slows down. Only way to clean that up is to write it out to a new file, just like any other database. The whole system will end up being faster because of it, if the registry overhead was causing a slow down.
Fallback option calls the Old School Windows API just like Erunt and the others to write the registry to new files. So you will notice they will always be smaller than the ones in the system32\config folder.
MS says they prefer to use VSS because of volatile registry keys. But that seems to be more server related as I havent ever found a workstation that had a program running that was using volatile registry keys. In fact I dont know of any programs that do lol
(Firefoxes spell check is a total joke, the words it misses is insane)
--- Quote ---5. Good question. I wish I had been more specific in my first post. I had to look at my own description of the problem, which was simply: "My own user account did not have access to UsrClass.dat." I should have listed the ACLs. [SIGH] Right now my system is in what I call a "State of grace" and I'm loathe to mess with it. But this never lasts long (Microsoft sees to that). So next time I have to mess around, I will look at exactly what the issue is. Sorry I can't be more specific on this one.
I did just try something, though. I backed up my ID's UsrClass.dat using RB and RegBak, as closely as possible in time. I thought the files backed up would be identical, but they're not. I see two bytes at the very beginning of the file that differ. I retried and the same was true again. No more detail as I assume this is just because of the file being updated normally by Windows.
But another difference was that RB had no attributes for UsrClass.dat turned on, other than the "c"ompression bit. RegBak saved UsrClass.dat with "a"rchive, "h"idden, and "c"ompression. Now that I've typed that, I can't see why it would matter. :undecided:
The ACLs on both saved UsrClass.dat files are identical, though, including the owners (Administrators).
--- End quote ---
The program calls VSS to make a shadow copy, then it maps that copy to a drive letter and then calls the FileCopy api in windows and tells it to copy the files to the backup folder. I dont make any calls to read or set the permissions on the file or the flags set just as compressed or hidden or anything. It lets the Windows API handle it.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx
On that page you will see that it has a Flags options, the only flag my program calls is "COPY_FILE_RESTARTABLE"
Also relooking at the page I found this about the file security. But again this is for the security of the file itself and not the permissions of the actual registry keys
--- 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.
--- End quote ---
So that means that when the file is copied it gets the permissions set by the parent folder.
In fact I find it odd that the file was marked as compressed, it shouldn't be, unless you compressed your whole drive. I wonder if that is the unknown variable I have been looking for.
I never compress my drives, slows everything down. If your drive isnt compressed then why is he registry file marked that way?
Shane
indrawn:
Sorry, I meant to mention that I have the backup directory compressed. Not the whole drive, just the dir. This is a new thing though. When I started seeing this issue, I didn't have the dir compressed.
Obviously, then, the "c" flag is appropriate. Nothing wrong here. Can't see why the "a" flag would matter. Not sure why the difference in "h" flags, though.
Thanks. Please get some sleep! :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version