superfile icon indicating copy to clipboard operation
superfile copied to clipboard

Crash when copying or cutting large directory

Open booth-w opened this issue 7 months ago • 2 comments

Describe the bug Inconsistent crash when copying or cutting a large directory. This time it crashed at 74% copying a 307GB directory of 1,250 files but it has happened before with one only 50GB large.

To Reproduce Steps to reproduce the behavior:

  1. Copy or cut
  2. Paste

Expected behavior Copies or cuts without crashing

Screenshots It first happened a while ago but I couldn't get the stack trace because it didn't exit cleanly, so for a while, all I could get was this:

Image

But I got it this time by running it with 2>> superfile.log

I had debug logging disabled so .local/state/superfile/superfile.log didn't have anything.

System information (please complete the following information):

  • OS: Arch Linux
  • Version 6.14.6-arch1-1
  • Superfile Version: v1.2.1-184-g0c15880

booth-w avatar May 18 '25 10:05 booth-w

Superfile's file operation code isn't written in a very scalable way, at least thats what I feel. There are other similar known issues for example :

  • https://github.com/yorukot/superfile/issues/571
  • https://github.com/yorukot/superfile/issues/782
  • Performance tagged issues - https://github.com/yorukot/superfile/issues?q=state%3Aopen%20label%3A%22performance%22

What we need is a thorough reviewing and revamp (rewrite of some part of the code if necessary), and some benchmarking tests which validates performance and functionality for operations at high scale.

lazysegtree avatar May 18 '25 12:05 lazysegtree

RCAing this specific issue instance is hard, unless we have a clear reproduction mechanism. But we could look at the code and figure out some possible code paths, that could lead to this.

lazysegtree avatar May 18 '25 12:05 lazysegtree

Image

Observed crash while copy a directory with 100K files.

lazysegtree avatar Jun 06 '25 12:06 lazysegtree