Network location speed vs mapped network drive speed

[ryarco]

Hi,

If I go to a location such as "\\company.internal\projects\folderA" XYplorer freezes for quite a while before showing the contents of that folder (15 seconds). If I go to "P:\folderA" where P:\ is mapped to "\\company.internal\projects" it loads instantly. I am wondering why it takes so long to find the files when given the absolute network path.

Note that:
* Subsequent visits to "\\company.internal\projects\XXXXX" is fast until I restart XYplorer
* When first starting XYplorer while pointing to "\\company.internal\projects\XXXXX" I get a tab that says "XYplorer was closed with this tab pointing to a network location, Click the icon to browse the network location now." clicking on the icon give me the error message "Location currently not available"

This is a problem for me as I am given network path links (and not mapped network drive links) quite a lot.

Thanks

[Borut]

I am also experiencing the same for a long time.

While waiting, the message "enumerating servers" is being shown. This happens only when accessing a \\server location for a first time in a session. I have the option "Assume that servers are available" checked. Can this server enumeration be avoided?

When "Cache network servers" is checked, things happen instantly. However, the file "server.dat" is quite a security problem for a portable use. (Have been hoping for a good security solution for a long time...).

[Leito]

Same here. This is the main source of XYplorer hanging for me.

[ryarco]

I am also experiencing the same for a long time.

While waiting, the message "enumerating servers" is being shown. This happens only when accessing a \\server location for a first time in a session. I have the option "Assume that servers are available" checked. Can this server enumeration be avoided?

When "Cache network servers" is checked, things happen instantly. However, the file "server.dat" is quite a security problem for a portable use. (Have been hoping for a good security solution for a long time...).

Thanks for the info Borut! I also get the "enumerating servers" message. The "Cache network servers" tip was a good one, it is now usable again. What you mean about the "server.dat" file being a security problem, couldn't find much info online. I guess that it won't be a major problem for me though as I am using an installed version on my work computer for accessing the work file servers.

[Borut]

Nice that it helped you. Yes, you probably have no reason for any concern.

I was referring to the file <xydata>\servers.dat in XYplorer's data path, which contains more or less easily readable server names. I do not want such information to be on my USB stick! I also do not want to mix server names from different networks in it. Even more, when one unchecks the "Cache network servers" option, the file or its content is not being deleted. One has to delete it explicitly.

But all that is part of a broader topic of XYplorer being such an extremely good and extremely portable application and at the same time not being concerned about security of the internal data.

[admin]

"Cache network servers" is the way to make it fast. I don't see any other way.

[aloishammer]

"Cache network servers" is the way to make it fast. I don't see any other way.

Enabling this option actually slows all network (SMB / CIFS) operations to a crawl and makes XY unusable for me.

How are you enumerating servers in the first place? If you have WINS servers available, querying them for server names should get you a response almost instantaneously, unless the servers are badly misconfigured. (I've tried this. XY is still weirdly slow and periodically starts to 'enumerate network servers' for no obvious reason'.) In this case, there is a single master browser on the network (Samba 4.4.x) with nmbd running and configured as a simple DNS proxy.

No other browsers or even Windows services (RPC, SMB, WINS, netlogon--take your pick) are available on this network or any network that the machine XY's running on knows about.

I've also tried the sane, modern case from the beginning: 'disabling' NetBIOS, which stops Windows from trying to contact NetBIOS local master browsers, or broadcast for them (or attempt to broadcast to win local browser elections), at which point 100% of network name requests should be filled by DNS. All 'NetBIOS' (SMB) traffic happens directly machine-to-machine on 445/tcp and ports in the 135-139 range should be almost totally unused. (Almost like a real OS.) This is how every other system on the network is configured, if it's a Windows machine at all or offers any form of service via Samba; either one.

This last case works perfectly well for everything except XY, which seems to be doing its own thing, whatever that is. Even if it's port-scanning every known machine in the entire subnet (/24), it should get back a mass of TCP resets and ICMP unreachables and process them all in a second or two, tops.

Whatever's going on, XY should be 'enumerating' or whatever it's doing on a separate thread from the UI. I'm running it wide open as a multi-tabbed file manager; every time 'enumeration' happens, the whole thing locks up and Windows will start offering to kill it if it stays that way long enough.

All long, expensive operations that aren't critical to drawing the UI should not cause the entire UI (and the entire process / 100% of all threads) to lock hard. Please, think hard about moving the netcode to a minimum of one separate thread; probably several.

[admin]

"Cache network servers" is the way to make it fast. I don't see any other way.

Enabling this option actually slows all network (SMB / CIFS) operations to a crawl and makes XY unusable for me.

That's something I cannot explain. How can reading a cached value can be slower than enumerating a network? I think it's a hint that something else is the issue.

But for now, please compare the speed of these two ways to enumerate the network. Paste each line into the XYplorer address bar and press <enter>:

Code: Select all

::text get("network", 0); //use shell

Code: Select all

::text get("network", 1); //use NetServerEnum

[Borut]

At my place (Cache network servers NOT checked):

Code: Select all

::text get("network", 0); //use shell

needs 6 sec (which feel like eternity)

Code: Select all

::text get("network", 1); //use NetServerEnum

result appears instantly

(Have restarted XY before each test. Have not restarted the PC.)

[PeterH]

If I remember it right, on the first try "0" lasted some seconds, while all further reqests (0 and 1) were immediate. Restart of XY didn't reset that.

Today, after Win7 restarted, I first tried "1": very fast. All further tries were fast, too.

So it seems that Win also caches values.

[Borut]

I can confirm that "0" appears to be cashed (wherever, but I assume in XY during the current session) in this sense: After the XY restart, the "0" lasts some seconds (apparently always) and then later (without XY being restarted) it is instantaneous.

The "1" however appears to be instantaneous also on the first invocation (after XY being restarted).

[admin]

Hm, so it seems that the factory default should be changed to "1". Again. Sigh. This is tricky. When you search the change log for "NetworkNetServerEnum" you see that I'm flipping back and forth between the two settings. Some unknown factors seem to control which is better for which user/system.

I probably should add this tweak to configuration... but I don't like to put such advanced setting there... ... tricky...

Anybody else can confirm that NetworkNetServerEnum=1 works faster (while showing a complete listing*)?
* In case the listing is incomplete try this tweak: ShowAllServers=1 (only effective if NetworkNetServerEnum=1)

[Leito]

For me, on first try:

• shell: 48sec
• NetServerEnum: 10sec

[admin]

Thanks, I'm convinced and will change the factory default to 1.

[highend]

Please bring that to the ui level!