Post by Ragnusen Ultred
It is currently chugging away ... with 507GB free on the primary HDD...
The goal is to make the "wuaueng.dll" thing (it's not really a file) not
have errors on Linux.
So, to make the NTFS work better with dual-boot Linux, I ran the
"compact.exe /compactos:never" command on Windows 10, which uncompressed
8,210 files in 17,689 directories, in about five or ten minutes time.
When I looked at the HDD space, I had expected the free space to change,
but it didn't change at all, so, I admit I'm officially confused because I
had expected that global uncompression action to eat up some HDD space.
Since others on Linux have this same problem (and yet, they don't know why
but we do because we're ahead of the game on knowledge), I'll append the
next three explanatory and exploratory posts from Paul.
***** From Paul #1 ***** ***** From Paul #1 *****
OK, do Properties on wuaueng.dll.
In the CompactOS Yes state, the size_on_disk was smaller than the size.
Because it actually does compress when CompactOS is being used.
Now that you've run it, the size_on_disk and the size should match,
because the compact command has removed the compression. Or at least,
the disparity between size_on_disk and size should be a lot smaller
difference (less than a 4096 byte difference?).
If you use "nfi.exe" utility, your change should have removed the
"WOFCompression" alternate stream or item in the nfi information.
That label should be gone for the wuaueng.dll entry.
If you use the Linux utility, there should be no more "I/O error"
or "I cannot do anything because of a Reparse point" type errors
for wuaueng.dll and neighbors.
Items like the VFS reparse point, one I have been unable to remove
or work with, will continue to be a problem. This just fixes up
the System32 issue for us.
My backup is still running. You've spoiled at least half the surprise :-)
Thanks for the feedback.
***** From Paul #2 ***** ***** From Paul #2 *****
You may have been in too much of a rush.
As a refresher, this is the before.
$DATA WofCompressedData (nonresident)
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
Attribute Type 0x100 $TXF_DATA (resident)
Now, because I've made my backup, I run the command.
Completed uncompressing OS binaries.
22354 files within 19484 directories were uncompressed.
OK, first of all, the file handle has changed. It's gone
to a lower filenum# value, because the filenum# allocation
is supposed to grab the first free one.
However, I wasn't really expecting the filenum entry to move.
This was supposed to be an in-place change.
Now the bad news. It seems to have unlinked the WinSXS copy from
the System32 file.
logical sectors 375765952-375771391 (0x1665bbc0-0x1665d0ff)
Attribute Type 0x100 $TXF_DATA (resident)
You'll notice the second file, doesn't have any data clusters.
I'm going to have to "decode" what this means tomorrow.
Too tired to continue. The "Properties" of the second file,
don't indicate that it's empty, so I'm not in a panic.
I just don't understand why the files seemingly got unlinked.
I'll have to find out what STANDARD_INFORMATION means, and whether
it's some sort of extension mechanism. And whether WinSXS is still
"maintainable" this way.
***** From Paul #3 ***** ***** From Paul #3 *****
OK, did some more checking, and it looks like that structure is
"equivalent" to the first, minus of course the WofCompressedData things.
I ran SFC on the disk, and it didn't change the entries.
From Linux, the inode number (which equals the filenum# of Windows and
is stuffed with that number for keeping stat() happy), is 1338418. That
means, in fact, the NTFS file structure still considers 1338418 to be
the "boss" file entry, and 28032 to be the "caboose". SFC is happy, since
it wants to link 1338418 (as master), into System32 folder. That's what
the Windows servicing model is all about.
There's no point of me running DISM, to refill WinSXS and potentially
blow away 1338418. I'm convinced at this point, "nothing has changed"
except the CompactOS being changed back to not using reparse points.
Here is a picture of Ubuntu 16.03.3 and what it thinks of my
fixed up 16299.309 OS. Now I can rename wuaueng.dll if and when I want,
to wuaueng.dll.bak :-)Loading Image...
******************** ******************* ***************
The goal here is to solve these errors when using Linux to change the
wuaueng.dll file name so that a user can permanently turn off Windows
updates on a dual-boot Linux system.
We're not there yet ... but we are a lot closer, together, than we would be