https://bugs.kde.org/show_bug.cgi?id=436919
Pedro V <voidpointertonull+bugskde...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |voidpointertonull+bugskdeor
| |g...@gmail.com
Resolution|--- |WORKSFORME
Status|REPORTED |NEEDSINFO
--- Comment #7 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
Was the supposed reproducer method in comment 3 actually work to recreate the
problem, or was it just assumed to be good enough?
Suspected the "> 2 000 000" condition as a potential time waster, not
recommending targeting that, but for the sake of completeness I went for it.
Optimally there would be multiple directories used for best performance, but
went for just 2 in tmpfs for simplicity, running the following in
/tmp/test/test2/:
seq 0 2000000 | xargs -I% -P $(nproc) touch %
"Double bagged" the files as I was using Krusader for compressing, and it would
just "freeze" when right clicking on the directory containing the ton of files,
and figured it's easier to just add an extra layer instead of waiting for not
sure how long.
Neither Krusader nor Ark will confirm in reasonable time whether the package is
any good, but `7z l test.7z | wc -l` shows 2000024 which is close enough to
what's expected without getting into the details of cutting out extra
verbosity.
Generally I feel like this will be a duplicate of Bug #453452 , not having to
do anything with the count of files.
If that's the case, then suspected issues are:
- 7z being rather unfriendly, not handling all files properly, symbolic links
being one common example
- Ark swallowing the errors of the 7z tool instead of properly propagating them
which is the more serious problem as there's a fake success
--
You are receiving this mail because:
You are watching all bug changes.
