Author Topic: Improvements for windows repair  (Read 7027 times)

0 Members and 1 Guest are viewing this topic.

Offline g1o2r3a4z5d6

  • Newbie
  • *
  • Join Date: Feb 2014
  • Posts: 2
  • Karma: 0
    • View Profile
Improvements for windows repair
« on: February 04, 2014, 04:24:04 am »
I have windows 7 home premium sp1 x64. I was trying to fix multiple nested application data folders, however neither junctionbox nor junktidy succeeded. I was trying to repair Wmi with Windows repair program but it said the filename was too long (due to application data folders). I was thinking if you could add some repairs for application data issues but keep in mind that none of the above mentioned programs did the job. I think it's because of permissions being messed up so that even those programs could not access application data (deny to everyone). You could add more progressive method for resolving this issue probably some permissions workaround (if no one has permissions then even your program won't have them). That's the biggest problem I think. But you'll know for sure how to address this problem. Keep up the good work, I think your program is great so far.

Offline Willy2

  • Hero Member
  • *****
  • Join Date: Oct 2011
  • Posts: 1165
  • Karma: 18
    • View Profile
Re: Improvements for windows repair
« Reply #1 on: February 04, 2014, 04:51:08 am »
I have the same problem. Luckily I still had WR v2.11 which doesn't have this problem. Some of the changes in WR v2.20 cause this change in behaviour.

Offline g1o2r3a4z5d6

  • Newbie
  • *
  • Join Date: Feb 2014
  • Posts: 2
  • Karma: 0
    • View Profile
Re: Improvements for windows repair
« Reply #2 on: February 04, 2014, 05:22:07 am »
I've been able to remove application data folders manually (by installing take ownership registry key) then I deleted the nested Application Data folders and then locked them for everyone. I wish your program would do that instead.

Offline Willy2

  • Hero Member
  • *****
  • Join Date: Oct 2011
  • Posts: 1165
  • Karma: 18
    • View Profile
Re: Improvements for windows repair
« Reply #3 on: February 04, 2014, 06:04:14 am »
Yes, Permissions are always a "pain in the butt". Even Windows still contains a number of "Permission" bugs & symbolic link bugs. Don't remember where they were hiding.


Offline Shane

  • Administrator
  • Hero Member
  • *****
  • Join Date: Sep 2011
  • Posts: 9281
  • Location: USA
  • Karma: 137
  • "Knowledge should be shared not hidden."
    • View Profile
Re: Improvements for windows repair
« Reply #4 on: February 04, 2014, 06:21:48 pm »
Quote
locked them for everyone. I wish your program would do that instead.
My program actually does that on the repair file permissions.

I found out what is happening.

In v2.11 the repair program only asks for 1 privilege

'Call BeginSetPrivilege
Call LoadPrivilege(SE_DEBUG_NAME)

What I did in v2.2.0 is I add more so the program would have access to more things that normally it wouldnt, just like my reg backup does.

'Call BeginSetPrivilege
 Call LoadPrivilege(SE_DEBUG_NAME)
Call LoadPrivilege(SE_TAKE_OWNERSHIP_NAME)
Call LoadPrivilege(SE_RESTORE_NAME)
Call LoadPrivilege(SE_BACKUP_NAME)

So the new backup privilege is letting the program have access to folders that are normally blocked (Because backup programs still need to back those up). And every cmd.exe window the program creates gets the same access. So when it hits (for example)
"C:\Users\Shane\Local Settings" (This is normally denied)

If you look at the permissions for that folder you will see everyone is set to deny. Well the program gets allowed with the backup privilege. So the repair wmi window gets to look in there and then gets into a loop and why you see the problem.

Having the program be able to access more folders and settings is a good thing and can help repairs work better on machines, the key here is for me to change the repair wmi so that it skips those locations in the user profiles :-)

So your machine is ok, it was a new change I made and the side effect I didnt see happening :-)

Shane
« Last Edit: February 04, 2014, 06:23:23 pm by Shane »