If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
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? |
Ads |
#2
|
|||
|
|||
File date/time; direcotry date/time
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. |
#3
|
|||
|
|||
File date/time; direcotry date/time
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 |
Thread Tools | |
Display Modes | Rate This Thread |
|
|