XYplorer Beta Club

ckp wrote:well, the renaming solution is no good for me, because these cached files and names often change, get deleted and recreated with new names. hoping you can fix the bug in xyplorer?

That's for Don (XY's Creator) to say, and it may be an easy fix. But frankly, I still say that this is a very problematic thing to have going and it may easily trip up other programs too. What application are you using that is the source of these files and are there any advanced settings that you can access to control the naming?

Jerry is correct, XYplorer has a problem with all those different (hash) file extensions (for whatever reason).
Let's see if Don is able to fix that

@Jerry
Do you know any application where you can control how it's cache files are named? Obviously they must
be unique (but ofc this could have been done more easily by using it's hash in the file name and the same
extension for all)...

I use Launchbox, a front end for launching PC games and emulation games. It creates those files. i also submitted a ticket on their forum about this, but I would assume they will think it's more of a bug in xyplorer. That said, I think they should fix it on their end anyway, because it may be causing some of their own app to slow down. But I use both of these apps a LOT and would like them both fixed
I wouldn't be surprised if there are other cases out there like this that would just be better for xyplorer to handle, or at least match the speed of the native file browser in these cases.
thanks!!

ok if i remove that zip download link now from my dropbox? or maybe a developer will need to d/l it still?

You can delete it

highend wrote:@Jerry
Do you know any application where you can control how it's cache files are named? Obviously they must
be unique (but ofc this could have been done more easily by using it's hash in the file name and the same
extension for all)...

No, highend! But I still say shame on the folks who conceived this naming scheme. Even if it did work ok in XYplorer.

What is the problem I should fix? (Read the thread 3 times and in a fast way and could not spot it...)

XY doesn't like to display folder contents which contain a massive amount of individual file extensions
E.g.:
Create a folder named "a"
Create 50k files in it. Each with a different file extension
00001.<hash 1>
00002.<hash 2>
...
xxxxx.<hash x>

Enter that folder. Depending on the number of files it can take up more than a minute until
XY has loaded the complete folder

Leave that folder
Rename all file extensions to e.g. zip
00001.zip
00002.zip
...
xxxxx.zip

Enter that folder
XY loads in (normally) less than 2 secs (on our tests with ~65k files)

OK, thanks. Should be lightning fast in next version.

great, now I need to purchase a license! love to support software where issues you have get real attention like this!

just purchased lifetime. looking forward to the next update with this fix.

v17.50.0206 seems to fix it for this special case. Folder loading is practically instant. Good job!

Is there a specific reason why it does work now for files with "long" extensions (bot not for shorter ones)?

I can create the same problem as before with the new version if I create files like this (note:
No, I do not have a specific use case for these test files...)

<5digit base>.<same 5digit ext> Crawling slow to display the content of a folder that contains such files...

Right-clicking ~70k files is not a joy either.
It takes about 20 seconds before the context menu appears.
Configuration | Menus, Mouse, Safety | Context Menus | Custom items in shell context menu
is off

Configuration | Menus, Mouse, Safety | Context Menus | Hide shell extensions from shell context menu
activating it doesn't change the situation

File Explorer's context menu on the same 70k files is instant

You are looking at the downside of smartness.

XY is optimized for real world file systems in complex ways that I won't explain here.

The architectures of XY and WE are fundamentally different in some regards. One of these differences is surfacing here.

I could easily make it blindingly fast for your use case, but only at a price I don't want to pay: all normal lists would be a little slower.

Catch 22.

Any idea when a build/version will come out with this fix?

? 206 fixed it...