What is going on with 24.00.0600 (not responding)

[Vocalpoint]

Just doing some basic work on a known good and VERY well used network share - where every time I attempt to double click a file, open a WinRAR archive or even just move a file from folder to folder - XY seems to have nervous breakdown and instantly kicks up a "Not Responding" message in the top left of the interface.

Sometimes it takes 10 seconds for XY to figure out where it is and what it's doing - whereas Windows Explorer has no issues whatsoever.

I know that this type of thing (network file browsing and operations) has been some sort of long standing interesting experiment where the excuses fly and general discussions about an impossible task of replicating the innards of Windows Explorer are countlessly debated - but if one is going to actually commit to using XY for 100% of one's file operations AND we are on version 24 after years and years of development - shouldn't this thing just work on the network by now?

The most frustrating thing is that I have not made ANY changes to any XY settings that I have used for version after version and sometimes I have long stretches where XY does just work over the network. And then I hit something like this today.

Anyone have any tips that I may not have known about after 12+ years of using this software?

VP

[admin]

What makes you so sure this started with XY 24.00.0600 and not with something in Windows?

[Vocalpoint]

What makes you so sure this started with XY 24.00.0600 and not with something in Windows?

Well - I just reviewed about 5 posts on this board that all mentioned XY "not responding", "slow", "freezing" etc in just the top 20 threads.

I would counter with: What makes you think that .600/.700 does not have new/ongoing network issues? Or are you implying the code is perfect and it's just another chance to blame Windows?

What I can tell you is - I rarely come in here since XY is generally well behaved (pre-.600) and my absence from posting should tell you that I am not specifically triggered about anything at all.

But when I do take the time to report something like this - especially when it happens on practically every mouse movement on the network - this specific version MIGHT have something going on.

VP

[highend]

So you've used an older version before that didn't had these implications or you are using 0600 (since it's out) and it behaved fine (until now) and just started to misbehave?

[admin]

v24.00.0600 has been published 2023-02-01 20:00. If it had a new problem with network I would have heard about it way before today.

[Vocalpoint]

So you've used an older version before that didn't had these implications or you are using 0600 (since it's out) and it behaved fine (until now) and just started to misbehave?

Hard to say. I have had .600 on here for approx 7 days but did not perform any specific network tasks (as described) with XY on this share until 45 minutes ago.

For all I know - this issue may have been there the whole time but did not show itself until I did this specific task on this specific network share. That is all I know right now about .600.

As far as older versions go - I have performed this most basic type of general file maintenance on this network share for at least 4-5 years with countless versions of XY and have never seen this specific weird freezeout until today.

What I will do is access the same share with .600 from a different install and see what transpires. I have .700 in the queue to install as well - and will try that a bit later.

VP

[highend]

A better way to test then installing a newer version

You can download all versions from the beta thread > v21.90.0045.

So grab e.g. v23.90.0000, make a backup of your xy data dir, extract the archive, copy over the files and after starting that, confirm the downgrade.

Do that network test.

Find the last version that works until it doesn't work anymore

When done, overwrite your files with the ones from 0600 and restore your copy of your xy data dir.

[phred]

Is it possible the drive on which the network share lives goes into a sleep mode and needs time to wake up?

[Vocalpoint]

Is it possible the drive on which the network share lives goes into a sleep mode and needs time to wake up?

No such thing as sleep mode in this case - this is enterprise file server running at full steam 24x7x365. It is designed to be reliable, available and not subject to dozing off

But - a good observation/suggestion which I would address with - if it was a sleep issue - that would logically occur just once when accessing a sleepy drive the first time. The drive would spin up and stay spun up until a time constraint was reached again.

But in this case - I did 20 successive file operations over maybe 5 minutes and XY crapped itself each time for at least 5-10 seconds. Definitely not a sleepy drive issue.

Then I did a series of identical file operations on the same share with the same files but using Windows 10 File Explorer and of course it was like butter, fast, clean and accurate with nary a single message labelled "Not Responding".

Frustrating to say the least.

VP