On Thu, 12/19/2024 6:46 PM, Char Jackson wrote:
On Thu, 19 Dec 2024 15:45:18 -0500, Paul <nospam@needed.invalid> wrote:
The File Explorer, is one huge collection of the most daft code.
I was trying to delete. One folder of stuff in the Servicing\LCU folder.
The deletion dialog counts to 57000 items or so, and where normally the
"blowing sheets to the breeze" part would begin, it just stopped. It
did that twice, me canceling in both cases.
If you hadn't canceled, it very likely would have eventually appeared to come back to life. In reality, the operation wasn't really paused at all. Only the graphical display appeared to be paused. Behind the scenes, I'd bet it was still
churning away.
If you're deleting *to* the Recycle Bin, or deleting *from* the Recycle Bin, there's a bunch of stuff going on behind the scenes. Deleting *to* the Bin requires each item to be renamed, with the original name and the new name being
stored somewhere together. Deleting *from* the Bin requires loading the file containing the list of original file names and the corresponding new names into
memory, then for each item the original name has to be looked up to get the new
name, delete file with new name, update file of new-old names, update File Explorer view, do next, etc. It's a lot, and it doesn't scale well, but then Recycle Bin isn't a regular folder.
I frequently delete batches of 25,000 to 40,000 photos, but once the total was
around 130,000 photos, so I'm used to seeing minutes worth of no display updates
and gigabytes of memory being gobbled up. After working with large numbers of files like that, it's normal to check File Explorer memory usage and seeing upwards of 40GB being used. Over time, it falls back to a more reasonable value,
without requiring a reboot.
I flipped over to Terminal
and used the MSDOS "del" command, and that worked fine.
In a Win10 VM, I used
sdelete -z C:
which is used to flush white space with zeros (before doing
a Compact of the container). The command gets about 99% done and
stops. Up pops a notification "I have turned on Storage Sense
for you, you can thank me later". I reach into Settings and
turn Storage Sense off, and... the sdelete program will still
not finish what it was doing. I had to run it again, and on the
second run, it worked properly.
Yes, the code in there is "some kinda special".
As stated above, the Recycle Bin is far from being a regular folder. It works well enough when you keep the file count low, but it doesn't always scale well.
I don't think I've ever seen an official description of the renaming scheme that
goes on in there, but I suppose it exists somewhere. In short, when you view the
Recycle Bin in File Explorer, just keep in mind that there are no files actually
stored there with those names. Each of the names that you see is actually mapped
to the renamed file. Some file managers show you the actual file names, but File
Explorer doesn't (by design).
My comment was more about the consistency of the responses.
On one occasion, I can clean LCU, and the response remains
user-engaged. There is no stoppage.
With the LCU issue just spotted, I flipped over to Task Manager
and there was no busy work going on in the background. We were
just stopped. That's part of the reason I just killed it and
did it manually. If there was busy work in the background,
and CPU usage, I would have left it to complete.
When Windows Update stops, I have a few techniques to get it to
start again. These stoppages are related to the "fake saving-CO2
campaign", where Microsoft thinks it is more clever to have
to leave a PC running for some later part of the day, when
the Windows Update will complete. Well, as it turns out, the
Windows Update process may not like the network cable being
pulled. You can shove USB sticks with NTFS file systems
on them into the USB ports, then pull them out. Now, normally
that would do absolutely nothing, but the last WU I had jam up,
activity started again after a few of those.
Some of the deadlock-like behavior, isn't actually a deadlock,
it's an invisible policy being followed. It takes a while
to spot those, and see there is a pattern to it.
Even the bandwidth the DoSVC uses for acquiring Windows Updates,
has a pattern to it. If an OS receives regular maintenance,
and the updates are mostly up to date, you get to use half-link-bandwidth
for your download phase. If a VM is months behind on updates,
they get the lead out, and the link runs at full rate. There
are a few things you must not do while that is going on,
or it will shift down to half rate again.
Some activity on the machine, does have a pattern.
The File Manager delete one just spotted, I classified
that as an anomaly. You have to study these, use your tools
(Task Manager or whatever), and make up your mind whether
the response is somewhere in the normal range, or, your
chain is being pulled. That's the nature of good quality OS code.
Chain pulling. "I have turned on Storage Sense for you,
dumbass user, you can thank me later." Yes, the thank you note
is in the mail. Now, can I have the CO2 back, on the wasted
effort that got me there ? I'm very happy and proud of you,
that you have a Storage Sense, that you can fold blankets
and put them in the linen closet. Good Work Microsoft.
Paul
--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)