Rene Lamontagne wrote:
On 08/28/2018 8:39 PM, Paul wrote:
Rene Lamontagne wrote:
On 08/27/2018 8:15 PM, Ken Springer wrote:
On 8/27/18 12:35 PM, Ralph Fox wrote:
On Mon, 27 Aug 2018 07:08:00 -0600, Ken Springer wrote:

Ran some of the typical clean up programs, found nothing. Virus
scan,
SuperAntiSpyware, Adware Cleaner, and Malwarebytes. Not a single
issue
found.

What about the built-in Windows Disk Clean-up?

I'm looking for ideas as to how to discover what is using up the
space,
or at least telling W10 the space is in use.

Run Windows Disk Clean-up, click the button "Clean Up System
Files", and
while in "Clean Up System Files" check the space used by (for example)
"Windows Update Clean-up".


To run Windows Disk Clean-up

(a) Right-click on the drive in Windows Explorer and choose
"Properties".
On the Properties pop-up, "General" tab, click the button
"Disk Clean-up".

or,

(b) Click on the search magnifying glass icon on the taskbar and
type
"Disk Clean-up".


Hi, Ralph,

Disk Cleanup of System Files was one of the first things I did. :-)



Why is disk cleanup so cussedly slow when you tick the windows update
cleanup box.
I know there are a lot of compressed files to do but this is really
slow, Any way to do a manual delete of this stuff, not knowing where
its stored?

Rene

This doesn't answer your question, but it kinda hints at
what might be involved.

https://www.techrepublic.com/blog/wi...dows-7-and-8x/


The claim is, cleaning up Windows Update either deletes files
or it compresses files.

Installed programs on your computer, may have dependencies on WinSxS
contents. The Windows Update function, knows what software is
on the computer, and knows the dependencies. It may be using
a "manifest" file which is part of the installed program itself.

Scanning all the packages takes time.

In the example, WinSxS has 58000 files. Comparing the files to
the scanned results could take time.

I think I've found compressed files in the past from this operation,
but it's hard to say if the three hours it took to make those,
is purely a function of the compression operation. I thought
in the past, I could squeeze about 30NB/sec out of NTFS compression,
so to compress 3GB of content should not take 3 hours (based
on compression alone).

Knowing how evil this stuff is, I would blame the Windows Update
subsystem itself for the delay.

I tried to reproduce this, but as the article says, the
"option" to do this is only offered if content is found.
And I wasn't able to generate a scenario that made rubbish
appear. And if, by using an older OS, I trigger an OS
Upgrade and not a Windows Update Cumulative, it might wipe
the state of that stuff anyway (the system would conclude
the freshly upgraded OS was in an optimal state).

Also, lots of this stuff is single threaded. So it's not
like buying a 32-core processor makes all maintenance go
faster. The best you could do, is buy a 5GHz processor
and rely on the tiny speed bump, "to make it seem you
were winning" :-)

Paul

OK Paul. here is the story I just did a couple days ago, My C: drive had
grown from about 28GB to about 39.6 GB so I decided to run disk cleanup
and see if I could shrink it back, In disk cleanup system files I found
about 250 MB plus 4.5 GB in windows update cleanup.So I ticked its box
and let er rip (slowly) and then went for dinner and a game of cribbage
with my Son.
When I got back I ran it up tothe analyse mode and it showed that That
windows update cleanup was now down to 11 MB, So it did OK, Did a cold
boot on the System and Checked C: drive and it was at about 38.1 GB!!!
Crap! I only gained about 1.5 GB instead of the 4.7 I thought I would.
This was just an exercise to see what was happening, I don't need the
space There is at least 60 GB free on the SSD.

Rene

To study it here, I need the "right kind of messed up VM",
and I'm still trying to find one :-) My Easy Bake Oven
doesn't bake these things very fast.

Paul