Is there a setting to automatically refresh Windows 10 File Explorer, such
that when a file is created or deleted in a File Explorer window, it
appears or disappears immediately, rather than having to do a refresh?

On 1/2/22 5:10 PM, this is what Boris wrote:
> Is there a setting to automatically refresh Windows 10 File Explorer, such
> that when a file is created or deleted in a File Explorer window, it
> appears or disappears immediately, rather than having to do a refresh?
>
My last research IIRC said it was an old bug.

--
Linux Mint Cinnamon 20.2 64bit, Dell Inspiron 5570 laptop
Quad Core i7-8550U, 16G Memory, 512G SSD, 750G & 1TB HDDs

Big Al <Bears@invalid.com> wrote in news:sqta27$4tr$1@dont-email.me:

> On 1/2/22 5:10 PM, this is what Boris wrote:
>> Is there a setting to automatically refresh Windows 10 File Explorer,
>> such that when a file is created or deleted in a File Explorer
>> window, it appears or disappears immediately, rather than having to
>> do a refresh?
>>
> My last research IIRC said it was an old bug.
>

Yes, I do experience it sometimes on my Win7 machine.

Boris <Boris@invalid.invalid> wrote:
> Big Al <Bears@invalid.com> wrote in news:sqta27$4tr$1@dont-email.me:

> > On 1/2/22 5:10 PM, this is what Boris wrote:
> >> Is there a setting to automatically refresh Windows 10 File Explorer,
> >> such that when a file is created or deleted in a File Explorer
> >> window, it appears or disappears immediately, rather than having to
> >> do a refresh?
> >>
> > My last research IIRC said it was an old bug.
> >

> Yes, I do experience it sometimes on my Win7 machine.

Yeah, I wonder why MS doesn't fix it. :(
--
:) NY! Let's hope 2022 will B betta than da last 2! :) NY! Let's hope 2022 will B betta than da last 2! :) BD 2 Diablo game that turned 25 on eve!
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

ant@zimage.comANT (Ant) wrote in
news:raOdnYpCK9jyoE_8nZ2dnUU7-cednZ2d@earthlink.com:

> Boris <Boris@invalid.invalid> wrote:
>> Big Al <Bears@invalid.com> wrote in news:sqta27$4tr$1@dont-email.me:
>
>> > On 1/2/22 5:10 PM, this is what Boris wrote:
>> >> Is there a setting to automatically refresh Windows 10 File
>> >> Explorer, such that when a file is created or deleted in a File
>> >> Explorer window, it appears or disappears immediately, rather than
>> >> having to do a refresh?
>> >>
>> > My last research IIRC said it was an old bug.
>> >
>
>> Yes, I do experience it sometimes on my Win7 machine.
>
> Yeah, I wonder why MS doesn't fix it. :(

I sort of remember this bug was also in the XP era. I have an XP
machine up and running, but I haven't used it for a while other than to
find old files.

I just did some more searching about this bug, and some also do mention
it in XP. One so-called fix is a registry hack, but others say that the
hack doesn't work for them. Maybe it depends on your update level.
I've done registry hacks that didn't work as advertised, so I'm not
really interested to try another one.

Either a right click in an empty spot while in a File Explorer window to
expose the 'refresh' command, or simply pressing the F5 key is good
enough for me. Case closed.

On 3-Jan-2022 1:13 pm, Boris wrote:
> ant@zimage.comANT (Ant) wrote in
> news:raOdnYpCK9jyoE_8nZ2dnUU7-cednZ2d@earthlink.com:
>
>> Boris <Boris@invalid.invalid> wrote:
>>> Big Al <Bears@invalid.com> wrote in news:sqta27$4tr$1@dont-email.me:
>>>> On 1/2/22 5:10 PM, this is what Boris wrote:
>>>>> Is there a setting to automatically refresh Windows 10 File
>>>>> Explorer, such that when a file is created or deleted in a File
>>>>> Explorer window, it appears or disappears immediately, rather than
>>>>> having to do a refresh?
>>>>>
>>>> My last research IIRC said it was an old bug.
>>>>
>>> Yes, I do experience it sometimes on my Win7 machine.
>> Yeah, I wonder why MS doesn't fix it. :(
> I sort of remember this bug was also in the XP era. I have an XP
> machine up and running, but I haven't used it for a while other than to
> find old files.
>
> I just did some more searching about this bug, and some also do mention
> it in XP. One so-called fix is a registry hack, but others say that the
> hack doesn't work for them. Maybe it depends on your update level.
> I've done registry hacks that didn't work as advertised, so I'm not
> really interested to try another one.
>
> Either a right click in an empty spot while in a File Explorer window to
> expose the 'refresh' command, or simply pressing the F5 key is good
> enough for me. Case closed.
This must be one of the oldest Windows bugs known to man. It's just
always been there. I can't believe it would have been that difficult to
fix. Why didn't Microsoft ever get round to sorting it? Perhaps there's
a good technical reason?

On 1/2/22 7:40 PM, this is what malone wrote:
> On 3-Jan-2022 1:13 pm, Boris wrote:
>> ant@zimage.comANT (Ant) wrote in
>> news:raOdnYpCK9jyoE_8nZ2dnUU7-cednZ2d@earthlink.com:
>>
>>> Boris <Boris@invalid.invalid> wrote:
>>>> Big Al <Bears@invalid.com> wrote in news:sqta27$4tr$1@dont-email.me:
>>>>> On 1/2/22 5:10 PM, this is what Boris wrote:
>>>>>> Is there a setting to automatically refresh Windows 10 File
>>>>>> Explorer, such that when a file is created or deleted in a File
>>>>>> Explorer window, it appears or disappears immediately, rather than
>>>>>> having to do a refresh?
>>>>>>
>>>>> My last research IIRC said it was an old bug.
>>>>>
>>>> Yes, I do experience it sometimes on my Win7 machine.
>>> Yeah, I wonder why MS doesn't fix it. :(
>> I sort of remember this bug was also in the XP era.  I have an XP
>> machine up and running, but I haven't used it for a while other than to
>> find old files.
>>
>> I just did some more searching about this bug, and some also do mention
>> it in XP.  One so-called fix is a registry hack, but others say that the
>> hack doesn't work for them.  Maybe it depends on your update level.
>> I've done registry hacks that didn't work as advertised, so I'm not
>> really interested to try another one.
>>
>> Either a right click in an empty spot while in a File Explorer window to
>> expose the 'refresh' command, or simply pressing the F5 key is good
>> enough for me.  Case closed.
> This must be one of the oldest Windows bugs known to man. It's just always been there. I can't believe it would have been that difficult to
> fix. Why didn't Microsoft ever get round to sorting it? Perhaps there's a good technical reason?
To pour salt on a wound, Linux has the same feature. I do backups via tar (zip) and I watch the folder and get no progress. If I refresh,
I get that update and maybe one or two more then it stops.
So this is really a big bug across 2 operating systems. I'd like to hear from a MAC user.

--
Linux Mint Cinnamon 20.2 64bit, Dell Inspiron 5570 laptop
Quad Core i7-8550U, 16G Memory, 512G SSD, 750G & 1TB HDDs

On 3-Jan-2022 5:04 pm, Big Al wrote:
> On 1/2/22 7:40 PM, this is what malone wrote:
>> On 3-Jan-2022 1:13 pm, Boris wrote:
>>> ant@zimage.comANT (Ant) wrote in
>>> news:raOdnYpCK9jyoE_8nZ2dnUU7-cednZ2d@earthlink.com:
>>>
>>>> Boris <Boris@invalid.invalid> wrote:
>>>>> Big Al <Bears@invalid.com> wrote in news:sqta27$4tr$1@dont-email.me:
>>>>>> On 1/2/22 5:10 PM, this is what Boris wrote:
>>>>>>> Is there a setting to automatically refresh Windows 10 File
>>>>>>> Explorer, such that when a file is created or deleted in a File
>>>>>>> Explorer window, it appears or disappears immediately, rather than
>>>>>>> having to do a refresh?
>>>>>>>
>>>>>> My last research IIRC said it was an old bug.
>>>>>>
>>>>> Yes, I do experience it sometimes on my Win7 machine.
>>>> Yeah, I wonder why MS doesn't fix it. :(
>>> I sort of remember this bug was also in the XP era.  I have an XP
>>> machine up and running, but I haven't used it for a while other than to
>>> find old files.
>>>
>>> I just did some more searching about this bug, and some also do mention
>>> it in XP.  One so-called fix is a registry hack, but others say that
>>> the
>>> hack doesn't work for them.  Maybe it depends on your update level.
>>> I've done registry hacks that didn't work as advertised, so I'm not
>>> really interested to try another one.
>>>
>>> Either a right click in an empty spot while in a File Explorer
>>> window to
>>> expose the 'refresh' command, or simply pressing the F5 key is good
>>> enough for me.  Case closed.
>> This must be one of the oldest Windows bugs known to man. It's just
>> always been there. I can't believe it would have been that difficult
>> to fix. Why didn't Microsoft ever get round to sorting it? Perhaps
>> there's a good technical reason?
> To pour salt on a wound, Linux has the same feature.   I do backups
> via tar (zip) and I watch the folder and get no progress. If I
> refresh, I get that update and maybe one or two more then it stops.
> So this is really a big bug across 2 operating systems.   I'd like to
> hear from a MAC user.
>

Interesting. So perhaps there is a good technical reason why viewing
folder contents can't be updated automatically - without us having to
keep pressing F5? With all the knowledgable people contributing to this
newsgroup, surely there's someone who understands the reason why this
major inconvenience hasn't been resolved?

And while we're talking about File Explorer - when a folder is opened we
see (in details view) the size of all the enclosed files. But not those
of the enclosed folders. Fifteen years ago I'd accept that this could be
computationally challenging, but surely not now?

Malone,

> And while we're talking about File Explorer - when a folder is opened we
> see (in details view) the size of all the enclosed files. But not those of
> the enclosed folders. Fifteen years ago I'd accept that this could be
> computationally challenging, but surely not now?

Imagine opening a folder in the root of a multi-terrabyte drive. It would
take quite a while for the OS to iterate thru all the folders and files on
that drive just so you can see a grand total.

Now imagine that combined with the current subject : every time /anything/
changes in that drive it needs to do that again.

Also think of non-local drives like a NAS or on true remote server (over the
internet). The scanning of such drives could get painfully slow.

By the way : when I, on my ancient machine, right-click a folder and select
"properties" it does what you ask - showing a count of all folders and files
and total size.

Oh, and it took just almost exactly a minute to go thru a local folder
containing just 20 GByte in about 110.000 files. Extrapolated to a single
terra drive that would take 50 minutes. :-(

Regards,
Rudy Wieser

On 1/3/2022 3:25 AM, R.Wieser wrote:
> Malone,
>
>> And while we're talking about File Explorer - when a folder is opened we
>> see (in details view) the size of all the enclosed files. But not those of
>> the enclosed folders. Fifteen years ago I'd accept that this could be
>> computationally challenging, but surely not now?
>
> Imagine opening a folder in the root of a multi-terrabyte drive. It would
> take quite a while for the OS to iterate thru all the folders and files on
> that drive just so you can see a grand total.
>
> Now imagine that combined with the current subject : every time /anything/
> changes in that drive it needs to do that again.
>
> Also think of non-local drives like a NAS or on true remote server (over the
> internet). The scanning of such drives could get painfully slow.
>
> By the way : when I, on my ancient machine, right-click a folder and select
> "properties" it does what you ask - showing a count of all folders and files
> and total size.
>
> Oh, and it took just almost exactly a minute to go thru a local folder
> containing just 20 GByte in about 110.000 files. Extrapolated to a single
> terra drive that would take 50 minutes. :-(
>
> Regards,
> Rudy Wieser

With federated search, a lot of the information could be
kept in the windows.edb file. As well as being in the $MFT,
the information could be "compressed" in a sense, into
the Search Indexer windows.edb file.

You can do a search that involves file sizes, using Federated Search.

I have a million files indexed with Federated Search now. The
performance of a query, is "all over the place". Anywhere from
2 seconds to 60 seconds. In some cases, you'd swear the database
backed design, is as slow as using Agent Ransack (sequential search!).

But at least there are a number of criterion you can use
with the Federated Search.

The NTFS $USN Journal, "broadcasts" file changes, and that's how the
Indexer finds out that a file has changed. There's no reason that
File Explorer cannot be listening to those broadcasts too.

The "materials" are there to do a good job, but there are
undoubtedly some issues with scaling involved in building
a multi-window File Explorer that works with mapped network drives.
Plus you have an AV like Defender, sandwiched between the
file system and File Explorer, to "disturb" any careful design.

The File Explorer windows are independent of one another.
When a File Explorer window "rails on a core", the other
File Explorer windows remain responsive. This implies a
lack of careful coordination between them, when it comes
to information exchange.

Really, I don't see it as the "realm of the possible", that
they will start over again with File Explorer. It is what it is.
"F5 is an integral part of Windows." That's what it should
be telling you in the Dummies book. That's never ever going
to change. Not now. This is not like rewriting Notepad.
File Explorer is a huge job, with a giant test bench to be
run. And all sorts of strange bizarre behaviors underneath
(clusters are not copied in counting order).

Paul

On 3-Jan-2022 10:44 pm, Paul wrote:
> On 1/3/2022 3:25 AM, R.Wieser wrote:
>> Malone,
>>
>>> And while we're talking about File Explorer - when a folder is
>>> opened we
>>> see (in details view) the size of all the enclosed files. But not
>>> those of
>>> the enclosed folders. Fifteen years ago I'd accept that this could be
>>> computationally challenging, but surely not now?
>>
>> Imagine opening a folder in the root of a multi-terrabyte drive.   It
>> would
>> take quite a while for the OS to iterate thru all the folders and
>> files on
>> that drive just so you can see a grand total.
>>
>> Now imagine that combined with the current subject : every time
>> /anything/
>> changes in that drive it needs to do that again.
>>
>> Also think of non-local drives like a NAS or on true remote server
>> (over the
>> internet).  The scanning of such drives could get painfully slow.
>>
>> By the way : when I, on my ancient machine, right-click a folder and
>> select
>> "properties" it does what you ask - showing a count of all folders
>> and files
>> and total size.
>>
>> Oh, and it took just almost exactly a minute to go thru a local folder
>> containing just 20 GByte in about 110.000 files.  Extrapolated to a
>> single
>> terra drive that would take 50 minutes. :-(
>>
>> Regards,
>> Rudy Wieser
>
> With federated search, a lot of the information could be
> kept in the windows.edb file. As well as being in the $MFT,
> the information could be "compressed" in a sense, into
> the Search Indexer windows.edb file.
>
> You can do a search that involves file sizes, using Federated Search.
>
> I have a million files indexed with Federated Search now. The
> performance of a query, is "all over the place". Anywhere from
> 2 seconds to 60 seconds. In some cases, you'd swear the database
> backed design, is as slow as using Agent Ransack (sequential search!).
>
> But at least there are a number of criterion you can use
> with the Federated Search.
>
> The NTFS $USN Journal, "broadcasts" file changes, and that's how the
> Indexer finds out that a file has changed. There's no reason that
> File Explorer cannot be listening to those broadcasts too.
>
> The "materials" are there to do a good job, but there are
> undoubtedly some issues with scaling involved in building
> a multi-window File Explorer that works with mapped network drives.
> Plus you have an AV like Defender, sandwiched between the
> file system and File Explorer, to "disturb" any careful design.
>
> The File Explorer windows are independent of one another.
> When a File Explorer window "rails on a core", the other
> File Explorer windows remain responsive. This implies a
> lack of careful coordination between them, when it comes
> to information exchange.
>
> Really, I don't see it as the "realm of the possible", that
> they will start over again with File Explorer. It is what it is.
> "F5 is an integral part of Windows."  That's what it should
> be telling you in the Dummies book. That's never ever going
> to change. Not now. This is not like rewriting Notepad.
> File Explorer is a huge job, with a giant test bench to be
> run. And all sorts of strange bizarre behaviors underneath
> (clusters are not copied in counting order).
>
>    Paul

I would have thought the simplest way to resolve the view refresh issue
would be to add code to File Explorer that would effectively implement
an F5 immediately after any change in the contents of a folder. Surely
that wouldn't be very demanding?

Malone,

> Surely that wouldn't be very demanding?

You obviously have not even bothered to read what I posted.

Regards,
Rudy Wieser

On 1/3/2022 3:58 PM, malone wrote:

> I would have thought the simplest way to resolve the view refresh issue would be to add code
> to File Explorer that would effectively implement an F5 immediately after any change in the
> contents of a folder. Surely that wouldn't be very demanding?

When they test the code, it has to stand having a
hundred File Explorer windows open. Remember, that everyone
is different, and there will be people who leave a lot
of those running.

Various schemes you can imagine, would waste a lot of CPU
resources and would "behave slow" if scaled.

I don't think of it as a problem that can be easily solved.
Part of the problem, is the independence of the various
display windows, the variable timing, the "lost refresh"
events and so on. You don't really want N**2 behavior in
the code.

Take a look at how the Control Panels behave when you open
them. Have you ever been ready to click something, when it
moved ? Why is the display so slow to finalize ? These are
all side effects of the implementation.

When File Explorer copies files, it reverses the order of a
few of the clusters when it copies, then it settles down
to copy the rest in proper order. What kind of code would
do that ? Who in their right mind would copy clusters out
of order ? This was spotted when Vista first came out, by
Russinovich (the ProcMon guy).

Paul

Big Al <Bears@invalid.com> wrote:
[...]

> To pour salt on a wound, Linux has the same feature. I do backups
> via tar (zip) and I watch the folder and get no progress. If I
> refresh, I get that update and maybe one or two more then it stops.
> So this is really a big bug across 2 operating systems. I'd like to
> hear from a MAC user.

Which (Linux) 'file manager' and which kind of file-system are you
using?

As Rudy and Paul explained, this is anything *but* a simple matter and
it is *not* a bug.

If you don't have a journaled file system, it's basically impossible
to do (while not wasting way too much (disk) resources on a brute force
method). If you do have a journaled file system, it's only feasible if
the journal not only broadcasts file changes, but also which folders
contain those changed files, the latter being very unlikely.

Just for kicks, in (Windows) File Explorer do a right-click on
\Windows and select Properties and wait till it finishes. *That* is
what's needed to satisfy malone's wishes [1]!

So a general automatic refresh is impossible/unfeasible. At best one
could have an automatic refresh for some small (what is 'small'?) folder
with no or only a few small subfolders. But 1) that should be able to
be turned off and 2) would just result in other complaints.

[1]
"And while we're talking about File Explorer - when a folder is opened
we see (in details view) the size of all the enclosed files. But not
those of the enclosed folders. Fifteen years ago I'd accept that this
could be computationally challenging, but surely not now?"

On 1/4/2022 8:52 AM, Frank Slootweg wrote:
> Big Al <Bears@invalid.com> wrote:
> [...]
>
>> To pour salt on a wound, Linux has the same feature. I do backups
>> via tar (zip) and I watch the folder and get no progress. If I
>> refresh, I get that update and maybe one or two more then it stops.
>> So this is really a big bug across 2 operating systems. I'd like to
>> hear from a MAC user.
>
> Which (Linux) 'file manager' and which kind of file-system are you
> using?
>
> As Rudy and Paul explained, this is anything *but* a simple matter and
> it is *not* a bug.
>
> If you don't have a journaled file system, it's basically impossible
> to do (while not wasting way too much (disk) resources on a brute force
> method). If you do have a journaled file system, it's only feasible if
> the journal not only broadcasts file changes, but also which folders
> contain those changed files, the latter being very unlikely.
>
> Just for kicks, in (Windows) File Explorer do a right-click on
> \Windows and select Properties and wait till it finishes. *That* is
> what's needed to satisfy malone's wishes [1]!
>
> So a general automatic refresh is impossible/unfeasible. At best one
> could have an automatic refresh for some small (what is 'small'?) folder
> with no or only a few small subfolders. But 1) that should be able to
> be turned off and 2) would just result in other complaints.
>
> [1]
> "And while we're talking about File Explorer - when a folder is opened
> we see (in details view) the size of all the enclosed files. But not
> those of the enclosed folders. Fifteen years ago I'd accept that this
> could be computationally challenging, but surely not now?"
>

They have tried to fix it.

Even in 2012, there was a laundry list of "workarounds".
Just the size of the list, gives you some idea how
many things screw with it.

https://www.computerworld.com/article/2827156/what-to-do-when-windows-explorer-doesn-t-refresh.html

Paul

On Tue, 4 Jan 2022 at 13:52:17, Frank Slootweg <this@ddress.is.invalid>
wrote (my responses usually follow points raised):
>Big Al <Bears@invalid.com> wrote:
>[...]
>
>> To pour salt on a wound, Linux has the same feature. I do backups
>> via tar (zip) and I watch the folder and get no progress. If I
>> refresh, I get that update and maybe one or two more then it stops.
>> So this is really a big bug across 2 operating systems. I'd like to
>> hear from a MAC user.
>
> Which (Linux) 'file manager' and which kind of file-system are you
>using?
>
> As Rudy and Paul explained, this is anything *but* a simple matter and
>it is *not* a bug.

Hmm. I'd tend to disagree. Normally, it seems I _do_ have automatic
refresh in Explorer (I'm in 7): when I'm looking at an ordinary folder
on my default disc, and I use some software which creates a new file or
modifies an existing one (i. e. most software), the new or changed file
appears effectively immediately. Sometimes, this stops happening - the
new file and/or amended details still appear if I press F5 or View,
Refresh, but not automatically. Others have noticed it too (on assorted
versions of Windows). I notice it most when I've been doing certain
things, but I wouldn't say they are the cause, because it doesn't
_always_ happen when I do those things (and _possibly_ it happens when
I'm doing other things, though I can't remember it doing so, at least
recently).
[]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Remembrance of things past is not necessarily the remembrance of things as
they were. - Marcel Proust

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote:
> On Tue, 4 Jan 2022 at 13:52:17, Frank Slootweg <this@ddress.is.invalid>
> wrote (my responses usually follow points raised):
> >Big Al <Bears@invalid.com> wrote:
> >[...]
> >
> >> To pour salt on a wound, Linux has the same feature. I do backups
> >> via tar (zip) and I watch the folder and get no progress. If I
> >> refresh, I get that update and maybe one or two more then it stops.
> >> So this is really a big bug across 2 operating systems. I'd like to
> >> hear from a MAC user.
> >
> > Which (Linux) 'file manager' and which kind of file-system are you
> >using?
> >
> > As Rudy and Paul explained, this is anything *but* a simple matter and
> >it is *not* a bug.
>
> Hmm. I'd tend to disagree. Normally, it seems I _do_ have automatic
> refresh in Explorer (I'm in 7): when I'm looking at an ordinary folder
> on my default disc, and I use some software which creates a new file or
> modifies an existing one (i. e. most software), the new or changed file
> appears effectively immediately. Sometimes, this stops happening - the
> new file and/or amended details still appear if I press F5 or View,
> Refresh, but not automatically. Others have noticed it too (on assorted
> versions of Windows). I notice it most when I've been doing certain
> things, but I wouldn't say they are the cause, because it doesn't
> _always_ happen when I do those things (and _possibly_ it happens when
> I'm doing other things, though I can't remember it doing so, at least
> recently).

What you describe is a simple context, but not the contexts which Rudy
and Paul - and hence I - commented on, i.e. the context of malone's
posting.

As I mentioned in the part you snipped, yes one could have an
automatic refresh for some relatively small folder and apparently that
is what File Explorer sometimes does (and sometimes doesn't). But a
general refresh, including subfolders and their files (as malone
expects) isn't feasible for the reasons we (Rudy, Paul and me) gave.

For example if you were looking at the \ folder in File Explorer and
something created/deleted/changed a file deep down in the \Windows tree,
File Explorer would have to recheck hundreds of thousands of files in
tens of thousands of folders, just to update the Size of the \Windows
folder as malone wishes [1]. And that's just for \Windows, not for the
other folders in \. And a few seconds later, File Explorer would have to
do the whole thing again, otherwise someone would complain that File
Explorer isn't refreshing.

[1] That's the very reason that for a folder (not a file) File Explorer
does *not* list a size in the 'Size' column.