Repair Reparse Points: Application Data junction repair - not

[GLykos]

Scan Reparse Points

Problem - Missing Default Reparse Point
Repair To Do - Create [same]
Type - JUNCTION
Original Path - C:\Users\User\Application Data
Target Path - C:\Users\User\AppData\Roaming

Repair Selected
Process steps are echoed to screen, all completed.

Rerun Scan.  Error persists.  Reboot for grins.  Error persists.

Am presuming that the reported (continuing) error is valid (until I hear otherwise from you) - am going to take a look at how to manually fix this.  In the meantime, this is to make you aware of the occurrence.

WR 4.22. Win 7 32 bit.

Regards,
George

[GLykos]

Sallying forth with a manual fix per guidance elsewhere in this forum:

mklink /J "C:\Users\User\Application Data" "C:\Users\User\AppData\Roaming"
errs out with "Cannot create a file when that file already exists."

Am imagining that the WR repair process did the same thing and silently encountered the same error.  Is this saying that the only problem is that there is no problem??

Thanks.

[GLykos]

Looking more closely, I see that C:\Users\User\ has both AppData\Roaming and Application Data directories.  The first is a normal-appearing directory structure, and the second advises that I don't have permission to access it (but can override that if desired).

mklink syntax is [options] <Link> <Target>, where target is the real directory, here User\AppData\Roaming, and User\Application Data is the link.

This appears to be set up correctly.  Why is WR reporting a problem to begin with, and what exactly is it?

Thanks again.

[Boggin]

I think you can ignore that but I'll pass this on for clarification.

[jpm]

Right. I believe that errors out if the folder / file / whatever is already there or permissions are wrong.  If the roaming is working fine than you can just ignore that.

[GLykos]

Thanks for letting me know it apparently is not a problem.  Why then was it reported as one?  In looking through the forums in search of some ideas of what to make of this, I discovered that the general impression when the WR repair doesn't repair the reported issue the behavior seems to be shrug and keep moving ahead with no understanding of what just happened.  I happened to come across one such posting where there was a reference to a "silent error", which got me looking at this more closely, and realized I can easily implement the related MkLink operation, feeding it the arguments provided in the (false, apparently) WR error report, and then see the MkLink request get promptly knocked back in no uncertain terms.  Would have thought that falsely reported errors then purportedly corrected (but in fact silently uncorrected) are anathema to a diagnostic and repair function.  Makes you wonder how many more there are, in what areas?