Tree not refreshing

[pissant]

I'm running the latest beta ... always. I have the auto-refresh option on. Yet, often, when a directory is moved or created outside of XYplorer, the tree doesn't get updated until I manually hit F4. This is a very consistent problem for me. Is this by design?

Here is a video showing a reproducible case (100% reproducible on my system):

http://www.mytempdir.com/927902 (222 KB)

In case it isn't obvious what's going on, in the video, I use mkdir to create a directory, but it doesn't appear until I hit F4.

[Gandolf]

This might be why it often happens, but not always.

If focus is on the directory (in the tree) where the external application creates the sub-directory, then it works i.e. the tree is refreshed.
If focus is on a sub-directory then it doesn't work and F4 is required to refresh the tree.

Also applies if focus is moved to the list.

However, if an external application deletes a directory then the tree is refreshed regardless of where focus is.

I think it's a bug!!

[admin]

In case it isn't obvious what's going on, in the video, I use mkdir to create a directory, but it doesn't appear until I hit F4.

mkdir does not trigger the necessary notifications. It's too old to know

EDIT: oh, you mean DOS mkdir. I thought you were talking VB... wait I have to check that...

[admin]

... However, if an external application deletes a directory then the tree is refreshed regardless of where focus is.

No. Whether create or delete, it's the same: I watch only the current branch. Anything outside it is not noticed (apart from adding/removing removable drives). Just checked Explorer: same thing!

[Gandolf]

It's more complicated than I thought. I depends on what application creates / deletes the directory and, since it's older applications that appear to have the problem, I suspect it is related to the MKDIR command. Why the older DELETE command works differently I don't understand.

I finally managed to make Explorer work, but it was hard going. No wonder I never use it!! As you say, the create / delete is consistent in that.

[admin]

It's more complicated than I thought. I depends on what application creates / deletes the directory and, since it's older applications that appear to have the problem, I suspect it is related to the MKDIR command. Why the older DELETE command works differently I don't understand.

The application that does the MKDIR or RD or DELETE must notify the OS of it which then broadcasts notifications to all open apps. If the deleting application keeps silent (typically older applications) nobody will know what happened.

[pissant]

I only used mkdir to show the problem... It has never actually happened with mkdir in my daily experience (as far as I remember). If you notice the directory names in the video, they're BitTorrent related... Meaning this problem happens when Azureus creates directories too.

I was using Windows XP mkdir... It's not DOS and it's not VB.

So I guess I'm out of luck, and XY simply can't always be counted on to refresh the tree. OK, thanks for the info.

Incidentally, I repeated the mkdir test shown in the video with Explorer. It does the same thing. Ain't this a pisser? It's crap like this that irritates me on a daily basis.

[admin]

I only used mkdir to show the problem... It has never actually happened with mkdir in my daily experience (as far as I remember). If you notice the directory names in the video, they're BitTorrent related... Meaning this problem happens when Azureus creates directories too.

I was using Windows XP mkdir... It's not DOS and it's not VB.

So I guess I'm out of luck, and XY simply can't always be counted on to refresh the tree. OK, thanks for the info.

As I said, it's not XY not listening, it's the other apps not talking.

[pissant]

As I said, it's not XY not listening, it's the other apps not talking.

Yeah, I got that and wasn't contrdicting you, it's just that it's an irritating problem. As the edit above says, I found that Explorer does the same thing (I had never tried before). I just wish there were some solution.

Thanks for the replies, and sorry for reporting a non-bug.