Char Jackson wrote:
On Wed, 6 Feb 2019 20:12:33 -0700, "Bill in Co"
surly_curmudgeon@earthlink wrote:

Char Jackson wrote:
On Wed, 6 Feb 2019 22:58:23 +0000, Java Jive
wrote:

On 06/02/2019 21:48, Bill in Co wrote:
Char Jackson wrote:
I've seen you mention that before, but I spend much of my Windows 7
time in Win Explorer and I never run into those problems.
You never run into "Access Denied" and the smoke and mirrors of junction
points?
Note that you'd be well advised to take a back-up image of the C: drive
before doing this ...

What I do is take ownership of the entire C: drive, this can be done by
rt-clcking it, choosing Security, Advanced, Owner, Edit,
Administrators, Replace on subs, OK.

This on its own may be enought to remove the 'Access denied' message.

Then I give Administrators Full Control over every file. This has to be
done from a command prompt launched as administrator:
icacls C:\*.* /C /Q /L /T /grant Administrators:F

Then I delete the daftest junction points that lead to circular
references, for example there's one inside every user's Application Data
folder heirarchy that points back up to Application Data. The rest I
ignore.
I've never run into any scenario where I'd be tempted to do all of that.

Yeah, but too, you said you spend more time on data drives, and not the OS
drives. That might be part of that, because I'll tell you, it can get to be
a real annoyance having to deal with all the obfuscations and convolutions
added by Windows 7 and its successors (I do presume). None of this
"impediment nonsense" exists in Windows XP, or the preceding OS versions
(unless I missed it).

The split is probably 70/30 or 60/40, so if working on the OS drive was
full of smoke and mirrors, I would have noticed back in, what, 2007?
When 7 was a new OS for me? So no, I wouldn't say there's any problem
working on the OS drive. I never noticed anything annoying and I'm not
sure why you're running into problems.


I don't think impediment nonsense is quite the right word for it.

D:PAI(A;OICI;FA;;;BA)
(A;OICI;FA;;;SY)
(A;OICI;0x1200a9;;;BU)
(A;OICIIO;SDGXGWGR;;;AU)
(A;;LC;;;AU)S:P(ML;OINPIO;NW;;;HI)
$Recycle.Bin

But it sure could use a decoder ring.

And yes, of course it looks cool and groovy in
a Properties Security tab. But that doesn't change the
fact that sometimes, you can't figure out what in that
mess, is actually blocking access.

The sad part is, that Linux isn't able to keep up with the
"improvements" in Windows 10, and if examining disks from Linux,
some attempts to probe an item receive "I/O Error". Which isn't
an I/O Error and does not mean your disk has a bad sector. Rather,
the error is "this file system driver doesn't know how to translate
the metadata it sees for this item". Even a third-party offering
from Paragon (offered because someone put effort into it
from a commercial perspective and wants to charge money),
even it cannot do the job. They only managed to solve one
of the issues, leaving others just as bad as they used to be.

The problem is, that Reparse Points don't have to be documented.
And in fact, it's rather a miracle that running CHKDSK from
Windows 7, on a Windows 10 C: , doesn't ruin it. Windows 7
doesn't necessarily understand what's going on either.
Windows 7 should not know how the "new compression method" works
on Windows 10.

And if you want some fun some time, try removing an item
with "VFS" in the path. Seems to be associated with Office
files a user doesn't own or need.

I guess the reason this isn't an issue for Macrium Reflect,
is it doesn't have to interpret the items like that. Just copy
the various component parts of them. But where that idea breaks
down a bit, is when Macrium restores and you change the partition
size, it does know how to move files around. And I'm not convinced
it could use the defragmenter API for doing that either. So maybe the
staff at Macrium could write a proper file system driver.

Paul