File date/time; direcotry date/time

Two more, related questions

1) Windows update has started again, (Maybe I started it. Not clear.)

And it's been running for 2 or 3 days and so far has dl'd 8% of the
download!

Yesterday, it was 2% and I wanted to see what file was dl'ing. And I
thought I had found it, because Resource Monitor showed it being written
to, although only between 1 and 3K per second.

And that file was Windows\SoftwareDistribution\Datastore\datastore.e db

After the abortive Anniversary Update, that file was 3gigs but now it
was just 255megs. I watched it and it didn't grow, it was exactly the
same size to the byte, and I didn't see it mentioned in the Disk portion
of Resource Monitor either. But later I noticed that the Date/Time
Modified kept changing every 5 or 6 minutes to the current time. Now
it's 2 days later and the time showing is 7:02:39 and the systray clock
shows 7:04:50, and in a few minutes the time on the file will change to
the now-current time. How can the time keep changing if the file size
isn't changing? Is it really being modified? What is the point of
that?


(The created and accessed date/time are last July 15 at the same time!)


2) In WinVista, I think, and earlier, the date on a directory was the
date it was created. But now the date seems to be the most recent
date/time that any file in the directory was changed. Have I got that
right? I find this new information (which I can get by looking at the
directory contents) less valuable than the old information, which is now
lost. Anyway I can get it to go back to the old way of reporting the
date/time for a directory? Maybe I could use the Date Created,
but it used to be I didn't have to have two date columns showing, and
sometimes there's no room for added columns. (Although now that I have a
wide monitor, maybe that won't be true). Is that the only way out?

On 28/09/2016 12:14, micky wrote:
Two more, related questions

1) Windows update has started again, (Maybe I started it. Not clear.)


No you are just an idiot and a troll. Your other nyms must be Yousuf
Khan, pjp, stan brown and David????

CAN YOU JUST **** OFF.




--
With over 400 million devices now running Windows 10, customer
satisfaction is higher than any previous version of windows.

micky wrote:
Two more, related questions

1) Windows update has started again, (Maybe I started it. Not clear.)

And it's been running for 2 or 3 days and so far has dl'd 8% of the
download!

Yesterday, it was 2% and I wanted to see what file was dl'ing. And I
thought I had found it, because Resource Monitor showed it being written
to, although only between 1 and 3K per second.

And that file was Windows\SoftwareDistribution\Datastore\datastore.e db

After the abortive Anniversary Update, that file was 3gigs but now it
was just 255megs. I watched it and it didn't grow, it was exactly the
same size to the byte, and I didn't see it mentioned in the Disk portion
of Resource Monitor either. But later I noticed that the Date/Time
Modified kept changing every 5 or 6 minutes to the current time. Now
it's 2 days later and the time showing is 7:02:39 and the systray clock
shows 7:04:50, and in a few minutes the time on the file will change to
the now-current time. How can the time keep changing if the file size
isn't changing? Is it really being modified? What is the point of
that?


(The created and accessed date/time are last July 15 at the same time!)


2) In WinVista, I think, and earlier, the date on a directory was the
date it was created. But now the date seems to be the most recent
date/time that any file in the directory was changed. Have I got that
right? I find this new information (which I can get by looking at the
directory contents) less valuable than the old information, which is now
lost. Anyway I can get it to go back to the old way of reporting the
date/time for a directory? Maybe I could use the Date Created,
but it used to be I didn't have to have two date columns showing, and
sometimes there's no room for added columns. (Although now that I have a
wide monitor, maybe that won't be true). Is that the only way out?

To disable Windows Update, you'd need to:

1) Disable Windows Update in Services. The obvious
sort of thing.
2) Disable Update Orchestrator.
3) Open Task Scheduler and remove everything Update
Orchestrator has installed. There are multiple scheduled
entries, some of which may put the WU service back
in service. When you see a Command Prompt window flash
on the screen at around the 2 minute mark after a reboot,
that's the delayed start of Update Orchestrator.

Like tag-team wrestling, Update Orchestrator throws
Windows Update back into the ring, after it's fallen out.
And keeps the fight going. You have to knock out both
opponents, to win.

And I don't plan on making any cute tables of registry
settings that do or don't work this week. As a general rule
of thumb, Windows Update will do as it pleases. Sure,
you can try that registry entry with the 0,1,2,3,4
options. But it doesn't have to work, or do anything.

*******

Taming a datastore.edb (Windows Update) problem is a lot
like taming a Windows.edb (Search Indexer) problem.

In your case, something is causing continuous updates
to the package state. So the process doing the scanning,
is mistaking something it sees, as a reason to update
the database.

In the case of the Search Indexer, if it indexes its own
folder, then it would go into a loop. With very similar
results. Lots of writes to the database, try and index
its own database, do more writes to the database noting
the changes, and so on.

Even if you do a Windows Update Reset, using one of
those scripts that turns off the four services and
deletes the contents of SoftwareDistribution, the
database will grow and behave in exactly the same
way after a rebuild. I found the same thing when
I detected looping behavior in Search Indexer. If
you rebuilt the index, the 1,2,1,2 files have
been indexed pattern, would show up again. You can't
fix **** like that, with simple resets. The file itself
is not at fault. Some code is at fault.

I googled and found all sorts of useless references to
"esent defrag". But instead, you'd need to figure
out where the thing repetitively works. Perhaps
some work with Process Monitor, would show the package
it is checking over and over again (ReadFile ops done
by wuauserv/wuaueng or the eauivalent of TiWorker code).

You could:

1) Do Win10 Clean Install. And blow away whatever
bad qualities were inherited from a qualifying OS.

2) Do more detective work. Once you figure out what
package needs to be removed or reinstalled or whatever,
it might stop.

When Windows Update actually downloads files, the BITS
service does the download. The file name used is BITSxxxx
and the downloader uses anonymous names like that to hide
what it is doing. Downloads should not go into a
database. The database tracks package state, what is
superseded and so on. So when you see writes to
datastore.edb and the size doesn't change, it's just
updating a table entry.

As for storage management on database.edb , if it needs
more room, it will bump the file size in power-of-two
chunks. For example, it might add a 256KB packet of zeros
to the end of the file. Then, as it needs space, it will
overwrite-in-place in those areas. And no matter what
allocation method is used, the file is highly fragmented.
Both inside and outside. Applying turd polish to it,
won't work :-)

Paul