XYplorer Beta Club

So this happened when moving a large folder (F:/large) into a new folder (F:/new) so the end result should be F:/new/large. F is a network location mounted via SMB.
The unprocessed files still sit in the old location, so the move did not complete after the error popped up.

Interesting, an uncaught error that needs to be handled more gracefully. You probably encountered a physical limitation there with the number of files moved. How many was it?

It's in the screenshot

Damn, I need the facepalm icon...

Okay, I assume this issue is caused by the growing amount of report data and/or undo data. The problem itself can't be fixed, but probably the file operation should take precedence over the report/undo, so the latter should just be thrown away when running out of memory.

PS: Since you apparently moved just one large folder, it can't be the undo data, so it must be the report data.

This seems related, happened when copying a relatively large folder:
Is there a way to mitigate this? Let XY use more memory or something?

Which XY version is that?

It's 23.00.0100, did you make some changes in a newer version?

Yes, please try the latest version 23.10.0000.

Here's an update:
So it looks like the copy operation gave up after reaching 2.61TB, however the folder was a little over 5TB. But the size seems less important the the file count. So far through anecdotal evidence it looks like it's safe to copy up to 500k files, maybe up to a million.

Also I swear I have windows 10, no idea why it's saying 8.1 there
Oh, and this was done on 23.10

It's not the bytes, it's the number of files. The way it is written now, there is a limit to this. 3 million files, come on...

Concerning the Windows version, please show echo <get os>;.

Thanks for confirming it's the file count that's the limit. Would it be difficult to increase or remote the limit? Seems I'll have to use windows explorer for backup operations.

EDIT: actually, it's a pain in the ass to use windows explorer for backups Unlike XY it breaks when copying files that have a path over 260 characters, and I have a lot of those

The limit is physical. Cannot raise it. The strategy is to split the job into parts. Until XY does it you can and have to do it yourself.

Thanks for considering a solution to this, I'll keep an eye on the changelog for if/when it gets implemented. I'll continue to manually split my file operations into smaller chunks in the meantime.