Discussion:
Have you ever seen "unsupported reparse point" warnings in ls output?
(too old to reply)
Uultred ragnusen
2018-03-21 17:06:01 UTC
Permalink
Q: Have you ever seen "unsupported reparse point" warnings in ls output?

On the Windows 10 newsgroup (tinyurl.com/alt-comp-os-windows-10), it was
suggested we can permanently disable Windows 10 updates by dual booting to
Ubuntu and then renaming a locked dll file inside the Windows 10 System32
hierarchy.
<http://www.pcbanter.net/showpost.php?p=3748324&postcount=11>

When I followed that interesting dual-boot advice, this is what resulted:
Loading Image...

What the heck is going on?
On decades on both Windows and Linux, I've /never/ seen those warnings!

Linux:
***@ragnusen: ls wuau*
ls: cannot access 'wuauclt.exe': Input/output error
ls: cannot access 'wuaueng.dll': Input/output error
ls: cannot access 'wuautoappupdate.dll': Input/output error
***@ragnusen: ls -l wuaueng.dll
lrwxrwxrwx 2 x x 25 Feb 9 20:37 wuaueng.dll -> unsupported reparse point
***@ragnusen:

Can someone explain what went on in Linux when I followed Paul's advice?
http://i.cubeupload.com/1ji0MX.jpg
William Unruh
2018-03-21 19:17:14 UTC
Permalink
Post by Uultred ragnusen
Q: Have you ever seen "unsupported reparse point" warnings in ls output?
But yours says that there is an Input output error.
Post by Uultred ragnusen
On the Windows 10 newsgroup (tinyurl.com/alt-comp-os-windows-10), it was
suggested we can permanently disable Windows 10 updates by dual booting to
Ubuntu and then renaming a locked dll file inside the Windows 10 System32
hierarchy.
<http://www.pcbanter.net/showpost.php?p=3748324&postcount=11>
You are brave. You follow the directions of a web site whose links are to porn
sites.
Post by Uultred ragnusen
http://i.cubeupload.com/1ji0MX.jpg
What the heck is going on?
On decades on both Windows and Linux, I've /never/ seen those warnings!
I have certainly seen the Input Output error messages for ls. It means that
the system is unable to understand the format of what it gets back probably
from the directory and the file.

And if you plug inthat phrase into google you get pointed to bug notices with
respect to the ntfs drivers.
Remember that the ntfs support in Linux had to be reverese enegineered.
Microsoft refuses to release the information as to the full specs of the file
system simply to stop things lile Linux from making drivers. So something
changed either in Windows, or in the ntfs driver.

eg: https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1728354


Microsoft is changing things and they do not feel it is their job to tell
Linux what they change.
Post by Uultred ragnusen
ls: cannot access 'wuauclt.exe': Input/output error
ls: cannot access 'wuaueng.dll': Input/output error
ls: cannot access 'wuautoappupdate.dll': Input/output error
lrwxrwxrwx 2 x x 25 Feb 9 20:37 wuaueng.dll -> unsupported reparse point
Can someone explain what went on in Linux when I followed Paul's advice?
http://i.cubeupload.com/1ji0MX.jpg
Uultred ragnusen
2018-03-21 23:33:10 UTC
Permalink
Post by William Unruh
Post by Uultred ragnusen
Q: Have you ever seen "unsupported reparse point" warnings in ls output?
But yours says that there is an Input output error.
Hi William Unruh,
Thanks for venturing an answer. To clarify, up near the top of the bottom
Ubuntu window is an ls command with this being the result:
http://i.cubeupload.com/1ji0MX.jpg
$ ls -l wuaueng.dll
wuaueng.dll -> unsupported reparse point
Post by William Unruh
You are brave.
You follow the directions of a web site whose links are to porn sites.
You know more than I do since I didn't know it's a web site to porn sites,
but now that I know that, I'll check it out more thoroughly! :)

Anyway, I've been on Usenet for decades where I ask questions, and, any
serious purposefully help suggestions, I explore if feasible.

In this case, changing the name of a file was feasible; but in the end, I
saw Unix warnings such as "unsupported reparse point" which I had never
seen before.
Post by William Unruh
I have certainly seen the Input Output error messages for ls. It means that
the system is unable to understand the format of what it gets back probably
from the directory and the file.
Hmmm. I wonder why Ubuntu can't understand the format of the file system
when it understand the format of the file system normally?

By that, I mean there's no other indication that Ubuntu doesn't understand
the Windows default file system other than this weird happenstance inside
the Windows System32 hiearchy.

Is there something different about the Windows file system?
Or just that System32 directory?
Or just that wuaueng.dll file?
Post by William Unruh
And if you plug inthat phrase into google you get pointed to bug notices with
respect to the ntfs drivers.
Yes. The results of the search for "unsupported reparse point" isn't
exactly enlightening.
https://duckduckgo.com/?q=ubuntu+17.10+unsupported+reparse+point
Post by William Unruh
Remember that the ntfs support in Linux had to be reverese enegineered.
Microsoft refuses to release the information as to the full specs of the file
system simply to stop things lile Linux from making drivers. So something
changed either in Windows, or in the ntfs driver.
eg: https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1728354
I hadn't found that bug, but I did find this one with both warnings:
https://bugzilla.redhat.com/show_bug.cgi?id=1377049
NTFS-3G gives "unsupported reparse point" for non-reparse-point hardlinks
Which says, in part:
"Reparse points are a way of triggering some specific processing for
accessing files, and the most usual ones are for redirecting to another
file (which ntfs-3g emulates as a symbolic link).
"Reparse point types which are not supported by ntfs-3g are shown as
"unsupported reparse point".

Also...
"On some computers (those which are powerful enough) Windows 10
compresses the system files, and a new type of reparse point has
been defined for triggering the decompression (see
http://jp-andre.pagesperso-orange.fr/junctions.html#other).
Since ntfs-3g-2016.2.22AR.1, reparse points trigger plugins,
and a plugin for decompressing Windows 10 system files has been
developed".
Post by William Unruh
Microsoft is changing things and they do not feel it is their job to tell
Linux what they change.
Thanks William Unruh,

These hits indicate I'm not the only one who is getting this warning,
where, for example, nobody really knows what's going on since these issues
are all unresolved:
https://unix.stackexchange.com/questions/203649/ntfs-3g-all-files-are-an-unsupported-reparse-point
https://superuser.com/questions/1270652/getting-i-o-error-and-unsupported-reparse-point-in-mounted-windows-partition-und
https://ubuntuforums.org/archive/index.php/t-1583075.html
https://www.linuxquestions.org/questions/linux-newbie-8/unsupported-reparse-point-rsync-834760/

This hazarded a guess what these strange things are:
https://serverfault.com/questions/742197/determine-target-of-ntfs-reparse-point
"These are probably de-duped files.
They are implemented with junctions on disk and the file system driver
handles reassembly. I doubt you will find a Linux tool that can deal
with them. And other Windows utilities for junctions won't understand
them because they were designed for regular junctions, not de-dupe
junctions."

This one isn't exactly the same warning, but is similar:
https://kb.datto.com/hc/en-us/articles/205944590-Symlink-to-Unsupported-Reparse-Point-Error-When-Trying-to-Restore-a-File
"These error messages can be caused when the volume you are
restoring has data deduplication enabled. The volume will
back up correctly, but you will be unable to use File Restore
to restore deduplicated data."

In summary, I guess I found a "bug" or maybe, more charitably, a lack of
functionality on Ubuntu 17.10 which doesn't seem to "completely" understand
a mounted Windows file system.

Is that your take also?
Carlos E.R.
2018-03-22 01:05:49 UTC
Permalink
Post by Uultred ragnusen
Post by William Unruh
Post by Uultred ragnusen
Q: Have you ever seen "unsupported reparse point" warnings in ls output?
But yours says that there is an Input output error.
Hi William Unruh,
Thanks for venturing an answer. To clarify, up near the top of the bottom
http://i.cubeupload.com/1ji0MX.jpg
$ ls -l wuaueng.dll
wuaueng.dll -> unsupported reparse point
Post by William Unruh
You are brave.
You follow the directions of a web site whose links are to porn sites.
None when viewed here. I guess APB does its job.
Post by Uultred ragnusen
You know more than I do since I didn't know it's a web site to porn sites,
but now that I know that, I'll check it out more thoroughly! :)
Anyway, I've been on Usenet for decades where I ask questions, and, any
serious purposefully help suggestions, I explore if feasible.
In this case, changing the name of a file was feasible; but in the end, I
saw Unix warnings such as "unsupported reparse point" which I had never
seen before.
It is in ntfs-3g code.

I had a look at /usr/lib64/libntfs-3g.so.84 with 'mc' and found the
string "reparse" more than once.

It is also present in /usr/bin/lowntfs-3g and ntfsinfo
Post by Uultred ragnusen
Post by William Unruh
I have certainly seen the Input Output error messages for ls. It means that
the system is unable to understand the format of what it gets back probably
from the directory and the file.
Hmmm. I wonder why Ubuntu can't understand the format of the file system
when it understand the format of the file system normally?
By that, I mean there's no other indication that Ubuntu doesn't understand
the Windows default file system other than this weird happenstance inside
the Windows System32 hiearchy.
Is there something different about the Windows file system?
Yes, ntfs.
Post by Uultred ragnusen
In summary, I guess I found a "bug" or maybe, more charitably, a lack of
functionality on Ubuntu 17.10 which doesn't seem to "completely" understand
a mounted Windows file system.
Is that your take also?
It is somewhat surprising that it works at all.
--
Cheers, Carlos.
Steven Petruzzellis
2018-03-22 05:37:07 UTC
Permalink
Post by Carlos E.R.
Post by Uultred ragnusen
Post by William Unruh
Post by Uultred ragnusen
Q: Have you ever seen "unsupported reparse point" warnings in ls output?
But yours says that there is an Input output error.
Hi William Unruh,
Thanks for venturing an answer. To clarify, up near the top of the bottom
http://i.cubeupload.com/1ji0MX.jpg
$ ls -l wuaueng.dll
wuaueng.dll -> unsupported reparse point
Post by William Unruh
You are brave.
You follow the directions of a web site whose links are to porn sites.
None when viewed here. I guess APB does its job.
Post by Uultred ragnusen
You know more than I do since I didn't know it's a web site to porn sites,
but now that I know that, I'll check it out more thoroughly! :)
Anyway, I've been on Usenet for decades where I ask questions, and, any
serious purposefully help suggestions, I explore if feasible.
In this case, changing the name of a file was feasible; but in the end, I
saw Unix warnings such as "unsupported reparse point" which I had never
seen before.
It is in ntfs-3g code.
I had a look at /usr/lib64/libntfs-3g.so.84 with 'mc' and found the
string "reparse" more than once.
It is also present in /usr/bin/lowntfs-3g and ntfsinfo
Post by Uultred ragnusen
Post by William Unruh
I have certainly seen the Input Output error messages for ls. It means that
the system is unable to understand the format of what it gets back probably
from the directory and the file.
Hmmm. I wonder why Ubuntu can't understand the format of the file system
when it understand the format of the file system normally?
By that, I mean there's no other indication that Ubuntu doesn't understand
the Windows default file system other than this weird happenstance inside
the Windows System32 hiearchy.
Is there something different about the Windows file system?
Yes, ntfs.
Post by Uultred ragnusen
In summary, I guess I found a "bug" or maybe, more charitably, a lack of
functionality on Ubuntu 17.10 which doesn't seem to "completely" understand
a mounted Windows file system.
Is that your take also?
It is somewhat surprising that it works at all.
--
Cheers, Carlos.
Pascal Hambourg does not know if there is a encumbered FOSS solution. At times, an inner world is more valuable than faithful descriptions of reality. After kill filtering all the socks, it's mainly just two trolls authoring almost all of the trolling. Yes. And both perfectly jealous dingbats. Virtually everything Pascal Hambourg says about Steve Carroll is dishonest of course, but he does not care. Now let us see knows C++, is an avid scripter, has forged Steve Carroll's ID, has motive and is a colossal whining mama's boy who, when he backs himself into a corner, posts all kinds of ridiculous crap even when he's _not_ flooding... AND... who works to attributes everything HE is doing on "anyone he can" and has for years? I have a custom setup I use as well, but it's a bit different.

Pascal Hambourg lies that he uses ChromeOS, while you know he never timed it on the fly and fully experienced it.
--
Get Rich Slow
https://groups.google.com/forum/#!topic/comp.os.linux.advocacy/tzMH39QmAmU
https://redd.it/6sfkup
http://comp.os.linux.advocacy.narkive.com/711dskzA/steven-petruzzellis-admits-he-can-not-back-his-claims-about-snit
Jonas Eklundh
Mike Easter
2018-03-22 01:58:11 UTC
Permalink
Post by Uultred ragnusen
$ ls -l wuaueng.dll
ls lists files or directories in directories. What is it supposed to do
when its target is a .dll file instead of a directory? That seems like
a misguided command.

The 'l' option just means long format.

There are a lot of (somewhat interesting) discussions about problems
with services which use the windows update module wuaueng.dll using a
lot of CPU or time. I saw a couple of those in bleepingcomputer.com.
--
Mike Easter
William Unruh
2018-03-22 03:35:49 UTC
Permalink
Post by Mike Easter
Post by Uultred ragnusen
$ ls -l wuaueng.dll
ls lists files or directories in directories. What is it supposed to do
when its target is a .dll file instead of a directory? That seems like
a misguided command.
It is a file. It lists it. But when it goes in and tries to for example figure
out what the length is or what the permissions are presumably the format is
all screwed up compared to regular ntfs files.
Post by Mike Easter
The 'l' option just means long format.
There are a lot of (somewhat interesting) discussions about problems
with services which use the windows update module wuaueng.dll using a
lot of CPU or time. I saw a couple of those in bleepingcomputer.com.
Uultred ragnusen
2018-03-22 16:07:30 UTC
Permalink
Post by William Unruh
It is a file. It lists it. But when it goes in and tries to for example figure
out what the length is or what the permissions are presumably the format is
all screwed up compared to regular ntfs files.
Here's more information from Paul, who provided those screenshots which
proved it's a /recent/ change that Linux hasn't yet caught up with,
apparently.

FROM PAUL

Microsoft appears to have added an additional nuisance
defense mechanism, against Linux edits.

It's well known (and expected in fact), that file system customization
done by slapping reparse points on stuff (adjunct metadata), cannot be
handled by a third-party file system mounter that doesn't know the
details. In the example here, Ubuntu cannot touch a subset
of the files in System32. There are still some non-essential
files in System32, that haven't been abused like that.

https://s14.postimg.org/wk819k3xt/Ubuntu_16_04_3.gif

Since a "dir /a C:\Windows\System32\wuau*" shows
no attribute whatsoever, what they've done is not
visible on the Windows side. It's some kind of
invisible feature, making it harder to tinker with
from Windows.

Paul
J.O. Aho
2018-03-22 16:34:08 UTC
Permalink
Post by Uultred ragnusen
Post by William Unruh
It is a file. It lists it. But when it goes in and tries to for example figure
out what the length is or what the permissions are presumably the format is
all screwed up compared to regular ntfs files.
Microsoft appears to have added an additional nuisance
defense mechanism, against Linux edits.
I guess the file you try to access is actually two different files, one
is accessed by 64bit applications and another by 32bit applications.

If you install two versions of notepad++, one 64bit and another 32bits
and you take the first one and add the line:

127.0.0.2 mysecondlocalhost

save it, then start the 32 bit notepad++ and open the file and tada,
there is no such line as you just had added. Open now the file with the
64bit notepad++ and it's back.

I wouldn't be surprised if the file you try to access is similar, those
the file the Linux sees is not a real file but a kind of a symlink.

It could be that another ntfs driver would work better, I don't know as
I don't really use spyware as OS and those I don't have the need of
loading ntfs driver.

The one in the kernel is more primitive and have just the basic support
for the ntfs file system, ntfs3g has better support for features and
should be the one to be used, but keep in mind it don't support
everything for example if you have a bitlocker device you will need
third party application to mount the file system.
To see which driver you are using, you can run: lsmod | grep ntfs
--
//Aho
Carlos E. R.
2018-03-22 19:15:34 UTC
Permalink
Post by J.O. Aho
It could be that another ntfs driver would work better, I don't know as
I don't really use spyware as OS and those I don't have the need of
loading ntfs driver.
I use ntfs on some usb sticks intended to be used for viewing long
movies in my TV set. FAT has a size limit (2 or 4 gigs, I don't remember
but does not matter), but ntfs doesn't and some tv sets are able to read
it. Yes, I was surprised. Sure, I would prefer the TV reading ext3. Life
is not nice always...
--
Cheers,
Carlos E.R.
J.O. Aho
2018-03-23 07:18:17 UTC
Permalink
Post by Carlos E. R.
Post by J.O. Aho
It could be that another ntfs driver would work better, I don't know as
I don't really use spyware as OS and those I don't have the need of
loading ntfs driver.
I use ntfs on some usb sticks intended to be used for viewing long
movies in my TV set. FAT has a size limit (2 or 4 gigs, I don't remember
but does not matter), but ntfs doesn't and some tv sets are able to read
it. Yes, I was surprised. Sure, I would prefer the TV reading ext3. Life
is not nice always...
Yes, I know there are devices that has issues with file systems and many
time for the strangest reasons, I have a router which only supports ntfs
storage if you want to use it as remote storage and the sad thing is
that the router do run Linux, while my iptv-box supports only XFS and
that is to obscure the data, so people won't be able to extract the
stored films they have downloaded to the box.

I do think people should make request for better file system support
when we buy devices, ask the sales person does it support
ext/btrfs/xfs/jfs and if they say no, ask why and ask for a discount for
it just supports less useful file system.
--
//Aho
Carlos E.R.
2018-03-23 13:16:55 UTC
Permalink
Post by J.O. Aho
Post by Carlos E. R.
Post by J.O. Aho
It could be that another ntfs driver would work better, I don't know as
I don't really use spyware as OS and those I don't have the need of
loading ntfs driver.
I use ntfs on some usb sticks intended to be used for viewing long
movies in my TV set. FAT has a size limit (2 or 4 gigs, I don't remember
but does not matter), but ntfs doesn't and some tv sets are able to read
it. Yes, I was surprised. Sure, I would prefer the TV reading ext3. Life
is not nice always...
Yes, I know there are devices that has issues with file systems and many
time for the strangest reasons, I have a router which only supports ntfs
storage if you want to use it as remote storage and the sad thing is
that the router do run Linux, while my iptv-box supports only XFS and
that is to obscure the data, so people won't be able to extract the
stored films they have downloaded to the box.
No, my point is that the device having support for ntfs is better that
only supporting fat, and that it is a good thing that they do support
ntfs at all. Or it can be exfat nowdays.
Post by J.O. Aho
I do think people should make request for better file system support
when we buy devices, ask the sales person does it support
ext/btrfs/xfs/jfs and if they say no, ask why and ask for a discount for
it just supports less useful file system.
Good luck with that.
Here they would call security and block your entrance again as a madman.

Or simply say no, and no way.
--
Cheers, Carlos.
William Unruh
2018-03-22 03:33:45 UTC
Permalink
Post by Uultred ragnusen
Post by William Unruh
Post by Uultred ragnusen
Q: Have you ever seen "unsupported reparse point" warnings in ls output?
But yours says that there is an Input output error.
Hi William Unruh,
Thanks for venturing an answer. To clarify, up near the top of the bottom
http://i.cubeupload.com/1ji0MX.jpg
$ ls -l wuaueng.dll
wuaueng.dll -> unsupported reparse point
Post by William Unruh
You are brave.
You follow the directions of a web site whose links are to porn sites.
You know more than I do since I didn't know it's a web site to porn sites,
but now that I know that, I'll check it out more thoroughly! :)
Anyway, I've been on Usenet for decades where I ask questions, and, any
serious purposefully help suggestions, I explore if feasible.
In this case, changing the name of a file was feasible; but in the end, I
saw Unix warnings such as "unsupported reparse point" which I had never
seen before.
Post by William Unruh
I have certainly seen the Input Output error messages for ls. It means that
the system is unable to understand the format of what it gets back probably
from the directory and the file.
Hmmm. I wonder why Ubuntu can't understand the format of the file system
when it understand the format of the file system normally?
Because Windows changed things.
Post by Uultred ragnusen
By that, I mean there's no other indication that Ubuntu doesn't understand
the Windows default file system other than this weird happenstance inside
the Windows System32 hiearchy.
Apparently some files are compressed and the decompression requires extra
software, and they changed things.
Post by Uultred ragnusen
Is there something different about the Windows file system?
Or just that System32 directory?
Or just that wuaueng.dll file?
I do not use or know Windows. I just googled the error phrase and came up with
some web sites.
Post by Uultred ragnusen
Post by William Unruh
And if you plug inthat phrase into google you get pointed to bug notices with
respect to the ntfs drivers.
Yes. The results of the search for "unsupported reparse point" isn't
exactly enlightening.
https://duckduckgo.com/?q=ubuntu+17.10+unsupported+reparse+point
Post by William Unruh
Remember that the ntfs support in Linux had to be reverese enegineered.
Microsoft refuses to release the information as to the full specs of the file
system simply to stop things lile Linux from making drivers. So something
changed either in Windows, or in the ntfs driver.
eg: https://bugs.launchpad.net/ubuntu/+source/ntfs-3g/+bug/1728354
https://bugzilla.redhat.com/show_bug.cgi?id=1377049
NTFS-3G gives "unsupported reparse point" for non-reparse-point hardlinks
"Reparse points are a way of triggering some specific processing for
accessing files, and the most usual ones are for redirecting to another
file (which ntfs-3g emulates as a symbolic link).
"Reparse point types which are not supported by ntfs-3g are shown as
"unsupported reparse point".
Also...
"On some computers (those which are powerful enough) Windows 10
compresses the system files, and a new type of reparse point has
been defined for triggering the decompression (see
http://jp-andre.pagesperso-orange.fr/junctions.html#other).
Since ntfs-3g-2016.2.22AR.1, reparse points trigger plugins,
and a plugin for decompressing Windows 10 system files has been
developed".
Post by William Unruh
Microsoft is changing things and they do not feel it is their job to tell
Linux what they change.
Thanks William Unruh,
These hits indicate I'm not the only one who is getting this warning,
where, for example, nobody really knows what's going on since these issues
https://unix.stackexchange.com/questions/203649/ntfs-3g-all-files-are-an-unsupported-reparse-point
https://superuser.com/questions/1270652/getting-i-o-error-and-unsupported-reparse-point-in-mounted-windows-partition-und
https://ubuntuforums.org/archive/index.php/t-1583075.html
https://www.linuxquestions.org/questions/linux-newbie-8/unsupported-reparse-point-rsync-834760/
https://serverfault.com/questions/742197/determine-target-of-ntfs-reparse-point
"These are probably de-duped files.
They are implemented with junctions on disk and the file system driver
handles reassembly. I doubt you will find a Linux tool that can deal
with them. And other Windows utilities for junctions won't understand
them because they were designed for regular junctions, not de-dupe
junctions."
https://kb.datto.com/hc/en-us/articles/205944590-Symlink-to-Unsupported-Reparse-Point-Error-When-Trying-to-Restore-a-File
"These error messages can be caused when the volume you are
restoring has data deduplication enabled. The volume will
back up correctly, but you will be unable to use File Restore
to restore deduplicated data."
In summary, I guess I found a "bug" or maybe, more charitably, a lack of
functionality on Ubuntu 17.10 which doesn't seem to "completely" understand
a mounted Windows file system.
As I said, ntfs is prorietary and not only does Windows not tell anyone what
the format is but threatens to sue people to try to find out.
And they researve the right to change it at any time.
Post by Uultred ragnusen
Is that your take also?
Yes.
Uultred ragnusen
2018-03-22 16:26:27 UTC
Permalink
Post by William Unruh
As I said, ntfs is prorietary and not only does Windows not tell anyone what
the format is but threatens to sue people to try to find out.
And they researve the right to change it at any time.
Hi William Unruh,

We figured most of it out.
https://postimg.org/image/71fowjkdp/

To date, only one tool on Linux can recognize the WofCompressedData files
that Microsoft instituted in a very recent update (2018-02) so it just
happened last month to all Windows 10 updates.

It will hit all the Linux forensic tools in spades since no Linux
recognizes the WofCompressedData, it seems.

Here's more information from Paul...where the Linux information is jam
packed in the forensic link he provided in the end of this note.

*************
Here's the dump for the 16299.309 file system. It shows
how they're abusing a compression declaration.

It was done in the 2018-02 Cumulative.

wuaueng.dll
Size 2,784,256 bytes
Size on disk 1,654,784 bytes

Created Feb.17,2018 <=== corresponds to 2018-02 Cumulative.
Modified Feb. 9,2018
Accessed Feb.17,2018

File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
$DATA WofCompressedData (nonresident) <===
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident) <===
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

And here is an example file from a 16299.125 install before the changes.

\Windows\System32\wuauclt.exe
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 2305160-2305239 (0x232c88-0x232cd7)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

So that's what was done.

*******

First hit in a search.

https://www.swiftforensics.com/2016/10/wofcompressed-streams-in-windows-10.html

Enjoy,
Paul
Jasen Betts
2018-03-22 05:13:07 UTC
Permalink
Post by William Unruh
Post by Uultred ragnusen
Q: Have you ever seen "unsupported reparse point" warnings in ls output?
But yours says that there is an Input output error.
Post by Uultred ragnusen
On the Windows 10 newsgroup (tinyurl.com/alt-comp-os-windows-10), it was
suggested we can permanently disable Windows 10 updates by dual booting to
Ubuntu and then renaming a locked dll file inside the Windows 10 System32
hierarchy.
<http://www.pcbanter.net/showpost.php?p=3748324&postcount=11>
You are brave. You follow the directions of a web site whose links are to porn
sites.
It's just the advert provider has characterised you as someone who
should be shown porn adverts.
--
This email has not been checked by half-arsed antivirus software
Uultred ragnusen
2018-03-22 16:32:46 UTC
Permalink
Post by Jasen Betts
Post by William Unruh
You are brave. You follow the directions of a web site whose links are to porn
sites.
It's just the advert provider has characterised you as someone who
should be shown porn adverts.
To take one for the team, I'm going to leave my WofCompressedData file as
it is, renamed, to see if Windows will brick me on the next mandatory
update (they bricked me in January where even the Microsoft store couldn't
revive the OS).
https://postimg.org/image/71fowjkdp/

That's the penalty for running experiments.

Another penalty is that I have a gift for finding bugs, where this is
basically a bug in all Linux distributions (or, more charitably, the Linux
distributions didn't know that Microsoft secretly changed things).
https://www.swiftforensics.com/2016/10/wofcompressed-streams-in-windows-10.html

The good news is that a detailed workaround does seem to exist on Linux,
which is outlined in this URL (but I don't fully understand what's going
on).
https://www.swiftforensics.com/2016/10/wofcompressed-streams-in-windows-10.html

If a linux expert can read this URL and tell the rest of us what it all
means, that would be helpful to all.

Here are some snippets...
If you mount a volume containing such compressed files in SIFT Workstation
or any linux system (they all use the same NTFS-3g FUSE driver), you will
see the message 'Unsupported reparse point' when trying to list these
files. Trying to access file contents will result in errors

That's because, on windows 10 [as of the 2018-02 cumulative update] there
is a new 'System Compression' option that compresses files using reparse
points. This is not the NTFS-based compression that earlier versions of
windows utilized, its different.

Windows can determine if the compression will be beneficial to the host
system and automatically trigger it!

The compression algorithms are XPRESS (4K, 8K, 16K) or LZX. While the files
are compressed on disk, if an application opens/reads such a file, it is
still getting the original decompressed data and all decompression is
handled on the fly automatically by windows 10.

As of now, no tools will recognize and decompress these files. Hence, you
can't read, keyword search or extract these files in their original
uncompressed form.

System compression utilizes reparse points and creates a new Alternate Data
Stream (ADS) having the name 'WofCompressedData'. The compressed data is
stored here. Reparse points are an NTFS feature that allow custom
implementation like this. However this means that other applications that
are not aware of this custom implementation will not be able to read/write
to that file. In encase (or other forensic tools), you can see the file and
the WofCompressedData stream. Clicking on the file just shows the contents
to be all zeroes. Clicking on the stream, you can get the compressed data,
but as of now, no automatic transparent decompression (as it does with NTFS
compressed files).

If you attach a windows 10 formatted volume/disk to a Windows 7 system, you
won't be able to access files as it does not know how to read them.

If you use SIFT or another Linux system, the fix is simple. A few months
back, Eric Biggers wrote a plugin to handle this. Its a plugin to the
ntfs-3g FUSE driver. Its available here:
https://github.com/ebiggers/ntfs-3g-system-compression
Steven Petruzzellis
2018-03-23 06:51:43 UTC
Permalink
Post by Uultred ragnusen
Post by Jasen Betts
Post by William Unruh
You are brave. You follow the directions of a web site whose links are to porn
sites.
It's just the advert provider has characterised you as someone who
should be shown porn adverts.
To take one for the team, I'm going to leave my WofCompressedData file as
it is, renamed, to see if Windows will brick me on the next mandatory
update (they bricked me in January where even the Microsoft store couldn't
revive the OS).
https://postimg.org/image/71fowjkdp/
That's the penalty for running experiments.
Another penalty is that I have a gift for finding bugs, where this is
basically a bug in all Linux distributions (or, more charitably, the Linux
distributions didn't know that Microsoft secretly changed things).
https://www.swiftforensics.com/2016/10/wofcompressed-streams-in-windows-10.html
The good news is that a detailed workaround does seem to exist on Linux,
which is outlined in this URL (but I don't fully understand what's going
on).
https://www.swiftforensics.com/2016/10/wofcompressed-streams-in-windows-10.html
If a linux expert can read this URL and tell the rest of us what it all
means, that would be helpful to all.
Here are some snippets...
If you mount a volume containing such compressed files in SIFT Workstation
or any linux system (they all use the same NTFS-3g FUSE driver), you will
see the message 'Unsupported reparse point' when trying to list these
files. Trying to access file contents will result in errors
That's because, on windows 10 [as of the 2018-02 cumulative update] there
is a new 'System Compression' option that compresses files using reparse
points. This is not the NTFS-based compression that earlier versions of
windows utilized, its different.
Windows can determine if the compression will be beneficial to the host
system and automatically trigger it!
The compression algorithms are XPRESS (4K, 8K, 16K) or LZX. While the files
are compressed on disk, if an application opens/reads such a file, it is
still getting the original decompressed data and all decompression is
handled on the fly automatically by windows 10.
As of now, no tools will recognize and decompress these files. Hence, you
can't read, keyword search or extract these files in their original
uncompressed form.
System compression utilizes reparse points and creates a new Alternate Data
Stream (ADS) having the name 'WofCompressedData'. The compressed data is
stored here. Reparse points are an NTFS feature that allow custom
implementation like this. However this means that other applications that
are not aware of this custom implementation will not be able to read/write
to that file. In encase (or other forensic tools), you can see the file and
the WofCompressedData stream. Clicking on the file just shows the contents
to be all zeroes. Clicking on the stream, you can get the compressed data,
but as of now, no automatic transparent decompression (as it does with NTFS
compressed files).
If you attach a windows 10 formatted volume/disk to a Windows 7 system, you
won't be able to access files as it does not know how to read them.
If you use SIFT or another Linux system, the fix is simple. A few months
back, Eric Biggers wrote a plugin to handle this. Its a plugin to the
https://github.com/ebiggers/ntfs-3g-system-compression
Daniel Lewis shreds Vennie 'The Moron' Bowden in every way possible. If the content is a bunch of gibbering baby sh*t. We know there are only a few people who do that. A shadow of false Daniel Lewis, projected wisely, at the wrong time. Vennie 'The Moron' Bowden doesn't have any clue what he is crying about.

I bet he thinks his wife's life was hard.



--
Do not click this link!

Jonas Eklundh Communication
Ragnusen Ultred
2018-03-22 05:15:24 UTC
Permalink
Post by Uultred ragnusen
Can someone explain what went on in Linux when I followed Paul's advice?
http://i.cubeupload.com/1ji0MX.jpg
Here's a post from Paul in the Windows thread, so that Paul doesn't have to
reproduce his information here...

https://postimg.org/image/9hhiawabh/
https://postimg.org/image/71fowjkdp/
https://postimg.org/image/u2wa2cwwt/

From Paul...

A reparse point, is a file system customization point.

It would be pretty hard for any Linux developer to "keep up" with that.
While one flavor of reparse point, a "Junction point", is a standard
construct (enough for Sysinternals.com to write a program for it), others
can be created at the drop of a hat.

For example, one flavor seemed to be created as part of a virtual file
system. Someone on the Linux side, would need to make a full time job of
this. (I did observe a thread in Fedora, where someone created a patch for
an issue like this, without so much as a wince or flinching. It doesn't
even look like they consulted a Linux environment NTFS wizard to make the
fix either. Which is fun. They actually fixed the $MFTMIRR error coming
from Win10-created NTFS partitions, by effectively just commenting out the
check. Just... like... that. They cannot do this for reparse points, no
matter how tempting.)

A Junction Point is just a link, a link that "allows moving
your home directory to D: ".

But other reparse points, really are quite custom, and that means we can't
use Linux to take care of them. Slapping a reparse point on a file, rather
than a directory, seems like a purposeful trick to keep Linux out.

I'm almost afraid to open my mouth, make a suggestion to defeat it, and
have them cut off another favorite way of doing things.

*******

Here are my test results.

Loading Image...

Loading Image...

Loading Image...

The results are consistent. All three Linux distros think

16299.15 OK
16299.125 OK
16299.309 wuaueng.dll is using a "reparse point"
which is alternately shown as an "I/O error" when it
cannot be stat()ed. It looks to me like "system files"
received this protection. Some files aren't
using it in the System32 directory.

Some change after .125 did this.

My suspicion is, the reparse point in this case, is a "null" one, with no
actual structure. I'll need to consult (some tool) to figure out if this is
the case.

So congrats to Microsoft, on another successful mission.
It's pretty obvious why this change was made.

This isn't an accident. Or a "rogue software designer".

You can check this out, to some extent, by using

dir /a

And a good place to test, is C:\users , as you'll get to see a couple of
the more benign examples. That will demonstrate what some of the attributes
look like.

But if you use Windows to check wuau* files

dir /a C:\Windows\System32\wuau*

then it doesn't show any attribute assigned to it.
Even though Linux has been convinced it's a reparse point.

Either they're using a trick which convinces Linux it's a reparse point, or
the reparse point has zero size (stored in the $REPARSE metadata or the
like).

Bastards (for wasting my time).
Steven Petruzzellis
2018-03-22 11:53:35 UTC
Permalink
Post by Ragnusen Ultred
Post by Uultred ragnusen
Can someone explain what went on in Linux when I followed Paul's advice?
http://i.cubeupload.com/1ji0MX.jpg
Here's a post from Paul in the Windows thread, so that Paul doesn't have to
reproduce his information here...
https://postimg.org/image/9hhiawabh/
https://postimg.org/image/71fowjkdp/
https://postimg.org/image/u2wa2cwwt/
From Paul...
A reparse point, is a file system customization point.
It would be pretty hard for any Linux developer to "keep up" with that.
While one flavor of reparse point, a "Junction point", is a standard
construct (enough for Sysinternals.com to write a program for it), others
can be created at the drop of a hat.
For example, one flavor seemed to be created as part of a virtual file
system. Someone on the Linux side, would need to make a full time job of
this. (I did observe a thread in Fedora, where someone created a patch for
an issue like this, without so much as a wince or flinching. It doesn't
even look like they consulted a Linux environment NTFS wizard to make the
fix either. Which is fun. They actually fixed the $MFTMIRR error coming
from Win10-created NTFS partitions, by effectively just commenting out the
check. Just... like... that. They cannot do this for reparse points, no
matter how tempting.)
A Junction Point is just a link, a link that "allows moving
your home directory to D: ".
But other reparse points, really are quite custom, and that means we can't
use Linux to take care of them. Slapping a reparse point on a file, rather
than a directory, seems like a purposeful trick to keep Linux out.
I'm almost afraid to open my mouth, make a suggestion to defeat it, and
have them cut off another favorite way of doing things.
*******
Here are my test results.
https://s14.postimg.org/462lq6o8x/Kubuntu_14_04_1.gif
https://s14.postimg.org/wk819k3xt/Ubuntu_16_04_3.gif
https://s14.postimg.org/83pvf5g2p/Ubuntu_17_10.gif
The results are consistent. All three Linux distros think
16299.15 OK
16299.125 OK
16299.309 wuaueng.dll is using a "reparse point"
which is alternately shown as an "I/O error" when it
cannot be stat()ed. It looks to me like "system files"
received this protection. Some files aren't
using it in the System32 directory.
Some change after .125 did this.
My suspicion is, the reparse point in this case, is a "null" one, with no
actual structure. I'll need to consult (some tool) to figure out if this is
the case.
So congrats to Microsoft, on another successful mission.
It's pretty obvious why this change was made.
This isn't an accident. Or a "rogue software designer".
You can check this out, to some extent, by using
dir /a
And a good place to test, is C:\users , as you'll get to see a couple of
the more benign examples. That will demonstrate what some of the attributes
look like.
But if you use Windows to check wuau* files
dir /a C:\Windows\System32\wuau*
then it doesn't show any attribute assigned to it.
Even though Linux has been convinced it's a reparse point.
Either they're using a trick which convinces Linux it's a reparse point, or
the reparse point has zero size (stored in the $REPARSE metadata or the
like).
Bastards (for wasting my time).
Several of us reported Autumn Nissen <https://www.instantcheckmate.com/people/autumn-nissen> years ago. As expected, it did naught to slow the fool.

I have worked in the technology field for almost 40 years. I've done business with Fortune 500 companies selling to the pharmaceutical industry and the communications industry. Never, not even once, was I on any occasion under a contractual obligation not to pre-install any OS the customer wanted. We sold AIXL, Sun, Symbian, etc. alongside Windows on our hardware. I think the point is more than to get them to listen to him. The point is likely to piss Audra Moore off for spraying outside groups he knows I frequent. His desire is to see Audra Moore annoyed by nonstop flooding. And hey, that could work.

Autumn Nissen <https://www.instantcheckmate.com/people/autumn-nissen> asked to be rated according to objective trolling criteria, which Audra Moore indulged.

You are seconds away from being in everyone's kill filter.



-
Best CMS Solution of 2017
http://www.5z8.info/hack-outlook_c6c9in_michaelangelo-virus

Loading Image...
Jonas Eklundh Communication
Ragnusen Ultred
2018-03-24 00:06:34 UTC
Permalink
Post by Ragnusen Ultred
So congrats to Microsoft, on another successful mission.
It's pretty obvious why this change was made.
Just to update the Linux side of this sordid affair where Microsoft
apparently played with NTFS in the February 2018 release such that Linux
hasn't caught up yet, I ran "sfc /scannow" on Windows, which not only
re-created the previously moved file - but which does other funky things.

Loading Image...

This is Paul's response and Andy's response, together, to that fact.

*****
ANDY:

You do know the whole purpose of sfc is to replace missing/corrupted files?
*****
PAUL:
If you think Ragnusen is surprised now, wait until he
runs nfi.exe and finds the file entry now has three filenames
in it :-)

It's going to be like this. Three things hard-linked together.

File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident) <=== An entry for the System32 name
wuaueng.dll
$FILE_NAME (resident) <=== An entry for the System32 name
wuaueng.dll.bak
$FILE_NAME (resident) <=== An entry for the WinSXS name
$DATA (nonresident)
$DATA WofCompressedData (nonresident)
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

There may be two files in the directory, but their clusters
of data will be one and the same. By using sfc /scannow, the side effect
result is that wuaueng.dll and wuaueng.dll.bak are all part of the
same file. You can delete either of those depending on desired result
(as long as Linux will let you).

Just a guess,
Paul
Ragnusen Ultred
2018-03-24 02:35:32 UTC
Permalink
More data on what Windows did to NTFS...

I decided to look into WOFCompression, and what I learned is:

1) The WOF stands for Windows Overlay Filesystem.
It's how they can implement this flavor of new compression,
without adding to the NTFS standard. Basically, yet another
abuse of reparse points for fun and profit. The overlay is like
a filter layer added to the file system, that notices the Reparse
point,
and uncompresses the "fake" file underneath to recover the "real" data.

This stuff was apparently used in Windows 8.1 and some
people were seeing it while debugging AV malware scan problems.

2) There's a tool that applies the policy.
The purpose of the tool, was probably intended for 32GB tablets,
not for my desktop system. My guess is, the .309 update applied
this policy, before the 5000+ files in the Cumulative got installed.

From an Administrator Command Prompt

compact.exe /compactos:query <=== find the current setting.
Is my OS compacted ???

compact.exe /compactos:never <=== change the policy to Never

What I don't know at this point, is whether this
actually "reverts" all the damage done. It will likely,
gradually, one Cumulative or System Upgrade after
another, put the files back in the original (unbuggered)
state.

Once in the unbuggered state, we'll be allowed to do a few things
from Linux again.

If you're going to use this setting of "Never", you'd want to
apply this and test it, before the next OS upgrade comes in.
So all the files in your System folder will get repaired.

To test this on my .309 system, I'm going to need to do a
a backup first. That will take time...

A person who owns a tablet, might not want to change this
policy. Or maybe they're even blocked from changing this
policy. Someone with a desktop using a hard drive, there's
not really a good excuse for Microsoft to be turning this
on. If you own an SSD, will saving 500MB of file space make
a difference to that 256GB SSD you bought ? Probably not.

Anyway, I'm off to test...

Paul
Ragnusen Ultred
2018-03-24 02:39:45 UTC
Permalink
Post by Ragnusen Ultred
What I don't know at this point, is whether this
actually "reverts" all the damage done.
Taking one for the team, I ran a smoke test when I saw this.
Loading Image...
*****
Microsoft Windows [Version 10.0.16299.248]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>compact.exe /compactos:query
The system is in the Compact state. It will remain in this state unless an
administrator changes it.

C:\WINDOWS\system32>compact.exe /compactos:never
Uncompressing OS binaries -
*****

It is currently chugging away ... with 507GB free on the primary HDD...
Loading Image...
Ragnusen Ultred
2018-03-24 16:39:04 UTC
Permalink
Post by Ragnusen Ultred
It is currently chugging away ... with 507GB free on the primary HDD...
http://i.cubeupload.com/wUQzaV.jpg
The situation turns out to be far more complex than I comprehend.
I admit that I'm confused, because the free space didn't change.
Loading Image...

***** **** ***
Paul responded...

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.
***** **** ***
Steven Petruzzellis
2018-03-25 10:39:12 UTC
Permalink
Post by Ragnusen Ultred
Post by Ragnusen Ultred
It is currently chugging away ... with 507GB free on the primary HDD...
http://i.cubeupload.com/wUQzaV.jpg
The situation turns out to be far more complex than I comprehend.
I admit that I'm confused, because the free space didn't change.
http://i.cubeupload.com/GiwfSF.jpg
***** **** ***
Paul responded...
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.
***** **** ***
It's like a front page hog. nospam has already decided what he is going to say before he calls. What you say does not matter. What owl says is beside the point.

Just about everything nospam says about anyone else is false. He has yet to realize people are not as stupid as he needs them to be.

Some time ago I did work on and showed some BASIC for the front end which is the only thing you can do when trying to avoid nospam's dishonest crap while reading with Google Groups. You never take responsibility for your own posts. Words that are easily found in a search. nospam can only speculate from the perspective of a programmer.

You are three seconds away from being in owl's kill file.

No one who isn't just using you for criminal purposes (isn't a troll) sees you as anything remotely close to decent. You have no one but nospam to credit for that.

The complete sham is chock-full of laughable gaps and relies heavily on nospam's 'user database' horseplay.

-
One Smart Penny
http://www.5z8.info/backyard-fireworks-disasters_t7w7pu_bombbuilding
https://groups.google.com/forum/#!topic/comp.lang.c/KDQrv8appR8

Jonas Eklundh Communication AB
Ragnusen Ultred
2018-03-24 17:32:44 UTC
Permalink
Post by Ragnusen Ultred
It is currently chugging away ... with 507GB free on the primary HDD...
http://i.cubeupload.com/wUQzaV.jpg
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.
http://i.cubeupload.com/GiwfSF.jpg

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.

Paul
***** From Paul #2 ***** ***** From Paul #2 *****
Hmmmm.

You may have been in too much of a rush.

*******

As a refresher, this is the before.

File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
$DATA WofCompressedData (nonresident)
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

Now, because I've made my backup, I run the command.

F:\>compact /CompactOS:never
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.

File 28032
\Windows\System32\wuaueng.dll
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 375765952-375771391 (0x1665bbc0-0x1665d0ff)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

File 1338418
\Windows\WinSxS\amd64_microsoft-windows-w..wsupdateclient-core_31bf3856ad364e35_10.0.16299.248_none_bc721a14145ef109\wuaueng.dll
$STANDARD_INFORMATION (resident)
$ATTRIBUTE_LIST (resident)
$FILE_NAME (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.

Paul

***** 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...

Paul
******************** ******************* ***************
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
alone.
Ragnusen Ultred
2018-03-26 17:47:20 UTC
Permalink
Post by Ragnusen Ultred
The goal is to make the "wuaueng.dll" thing (it's not really a file) not
have errors on Linux.
I think we can summarize that Microsoft sneaked in a WOF overlay on top of
the NTFS protocol as of the recent February 2018 release of Windows 10,
such that the wuaueng.dll file is a strange beast indeed, even on Linux, as
aptly explained in this thread.

What is this strange new Windows file-system beast (C:\Windows\System32\wuaueng.dll)?
http://www.pcbanter.net/showthread.php?t=1103450

Hence, we found a /simpler/ method of permanently turning off Windows
Update, which is described in this recent thread, where Linux is no longer
involved.

What is an effective way to tun off Windows 10 updates until YOU want them back on?
http://www.pcbanter.net/showthread.php?t=1103500
Steven Petruzzellis
2018-03-24 05:21:33 UTC
Permalink
Post by Ragnusen Ultred
Post by Ragnusen Ultred
So congrats to Microsoft, on another successful mission.
It's pretty obvious why this change was made.
Just to update the Linux side of this sordid affair where Microsoft
apparently played with NTFS in the February 2018 release such that Linux
hasn't caught up yet, I ran "sfc /scannow" on Windows, which not only
re-created the previously moved file - but which does other funky things.
http://i.cubeupload.com/pPEOsA.jpg
This is Paul's response and Andy's response, together, to that fact.
*****
You do know the whole purpose of sfc is to replace missing/corrupted files?
*****
If you think Ragnusen is surprised now, wait until he
runs nfi.exe and finds the file entry now has three filenames
in it :-)
It's going to be like this. Three things hard-linked together.
File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident) <=== An entry for the System32 name
wuaueng.dll
$FILE_NAME (resident) <=== An entry for the System32 name
wuaueng.dll.bak
$FILE_NAME (resident) <=== An entry for the WinSXS name
$DATA (nonresident)
$DATA WofCompressedData (nonresident)
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)
There may be two files in the directory, but their clusters
of data will be one and the same. By using sfc /scannow, the side effect
result is that wuaueng.dll and wuaueng.dll.bak are all part of the
same file. You can delete either of those depending on desired result
(as long as Linux will let you).
Just a guess,
Paul
Marek admitted Carroll repeatedly asked him to lie:

Marek <NPWdnVgF_NwsozXEnZ2dnUU7-***@giganews.com>:
-----
When I first tried to broker peace between you [Steve Carroll] and
Snit, you emailed me over and over again asking be to lie about
Glasser.
-----

And then Marek later admitted he DOES lie, but claimed he does it simply because it pleases him to do so:

Marek <keCdnc7hoMqpfy3EnZ2dnUU7-***@giganews.com>:
-----
| Why do you post your attacks and insults and lies if not to please
| the herd?

I do it to please me, Snit.
-----

Whatever his reason for lying, even Marek admits he lies and attacks and insults.

--
Get Rich Slow
https://groups.google.com/forum/#!topic/comp.os.linux.advocacy/tzMH39QmAmU
Jonas Eklundh
Arlen Holder
2020-04-21 03:15:55 UTC
Permalink
Post by Uultred ragnusen
Q: Have you ever seen "unsupported reparse point" warnings in ls output?
On the Windows 10 newsgroup (tinyurl.com/alt-comp-os-windows-10), it was
suggested we can permanently disable Windows 10 updates by dual booting to
Ubuntu and then renaming a locked dll file inside the Windows 10 System32
hierarchy.
<http://www.pcbanter.net/showpost.php?p=3748324&postcount=11>
http://i.cubeupload.com/1ji0MX.jpg
What the heck is going on?
On decades on both Windows and Linux, I've /never/ seen those warnings!
ls: cannot access 'wuauclt.exe': Input/output error
ls: cannot access 'wuaueng.dll': Input/output error
ls: cannot access 'wuautoappupdate.dll': Input/output error
lrwxrwxrwx 2 x x 25 Feb 9 20:37 wuaueng.dll -> unsupported reparse point
Can someone explain what went on in Linux when I followed Paul's advice?
http://i.cubeupload.com/1ji0MX.jpg
For the permanent Usenet record cross reference, given Ubuntu is a critical
way to prevent Windows from updating, please see also this related post
today on the canonical Windows 10 newsgroup:
o <http://tinyurl.com/alt-comp-os-windows-10>
o <http://alt.comp.os.windows-10.narkive.com>

From: John Doe <***@message.header>
Newsgroups: alt.comp.os.windows-10
Subject: Can I install 1709 and stay there?
Date: Tue, 21 Apr 2020 01:02:43 -0000 (UTC)
Message-ID: <r7lgnj$a4$***@dont-email.me>

Are we allowed, or can it be easily configured, to install an older
version (like 1709), then prevent the update machine from forcing us
into newer versions?
I know 1709 can be installed.
Can be held at that version?

From: Paul <***@needed.invalid>
Newsgroups: alt.comp.os.windows-10
Subject: Re: Can I install 1709 and stay there?
Date: Mon, 20 Apr 2020 22:24:19 -0400
Message-ID: <r7llfa$ndg$***@dont-email.me>

Disable wuaueng.dll (wuauserv executable), profit ???
Loading Image...

And when the installer DVD says "Checking for what's new at Windows"
or similar. What it's doing is looking for a later DVD image
to substitute for the one being used at the time. It might then
ask "download newer DVD image" or similar type language.
Say No to this. In the past, when it did that check, the check
wasn't wired up, but since 1909 came out, they wired that up
so if you used a 1709 disc, it's going to ask whether you'd
like a crusty copy of 1909 instead.

And if you're thinking of installing 1709 over 1909, as
a "Repair Install", I don't think it likes that particularly :-)
You could install 1909 over 1909, you could install 20H1 over
1909, but 1709 over 1909, it should whine if you do that.

Rename wuaueng.dll any time before it has a chance to go
sniffing for a new version on the 'net...
Paul

Note that the solution that worked successfully for me for multiple years
in preventing Windows 10 Pro from updating was to mess with this special
file named wuaueng.dll from a dual-boot Linux setup.

Regarding messing with "wuaueng.dll" (I do it from Linux as a dual boot):
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
<Loading Image...>
etc.

Paul and I worked on wuaueng.dll years ago...
<https://groups.google.com/d/msg/alt.os.linux/D7E7FQ1NLNk/8sG2-ofFBwAJ>

Where I was very successfully able to forestall Windows 10 Pro updates for,
oh, something like two years before the system eventually bricked itself so
badly during an update attempt that even the Microsoft Store couldn't fix
it after 3 days in their shop (elapsed time).

Unfortunately it's difficult to search the Windows 10 archives record:
o <http://tinyurl.com/alt-comp-os-windows-10>
o <http://alt.comp.os.windows-10.narkive.com>

But I found this on the Linux archives which may help the OP:
o *Have you ever seen "unsupported reparse point" warnings in ls output?*
<https://groups.google.com/d/msg/alt.os.linux/3XyLpV-Za9o/mHiUyE3EAwAJ>

Note the trick is to dual boot to Linux so as to access that Windows file
without Windows itself getting in the way (hibernation & faststart off).
--
Usenet allows purposefully helpful sharing of solutions for common benefit.
Corvid
2020-04-21 03:36:30 UTC
Permalink
/snip/
Post by Arlen Holder
Paul and I worked on wuaueng.dll years ago...
And the twit is trying to attach himself to Paul.
John Doe
2020-09-15 11:38:46 UTC
Permalink
Deranged nym-shifting troll...

see also...
=?UTF-8?B?8J+QriBDb3dzIGFyZSBOaWNlIPCfkK4=?= <***@cows.moo>
Banders <***@mailchute.com>
Corvid <***@ckbirds.org>
Cows Are Nice <***@nice.moo>
Cows are nice <***@cows.org>
Cows are Nice <***@cows.moo>
dogs <***@home.com>
Great Pumpkin <***@patch.net>
Jose Curvo <***@mymail.com>
Local Favorite <***@palomar.info>
Sea <***@coast.org>
Standard Poodle <***@poodle.com>
and others...
--
Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.yhxzq0GkjhLBn92zR4Tlsw.user.gioia.aioe.org!not-for-mail
Newsgroups: alt.os.linux
Subject: Re: Have you ever seen "unsupported reparse point" warnings in ls output?
Date: Mon, 20 Apr 2020 20:36:30 -0700
Organization: Aioe.org NNTP Server
Lines: 8
NNTP-Posting-Host: yhxzq0GkjhLBn92zR4Tlsw.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
X-Notice: Filtered by postfilter v. 0.9.2
Xref: reader01.eternal-september.org alt.os.linux:65295
/snip/
Post by Arlen Holder
Paul and I worked on wuaueng.dll years ago...
And the twit is trying to attach himself to Paul.
Loading...