https://bugs.kde.org/show_bug.cgi?id=484408
SDon <darkinosun...@protonmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |darkinosun...@protonmail.co
| |m
--- Comment #6 from SDon <darkinosun...@protonmail.com> ---
Created attachment 181768
--> https://bugs.kde.org/attachment.cgi?id=181768&action=edit
Dolphin memory usage
Hi, just adding a bit more info.
Ran into the same issue while copying a really large file from act as admin tab
to a regular tab. It actually moves it, but really slowly, it seems its doing a
copy first. While doing the copy, the memory usage of dolphin rises, with large
enough file to a point where the kernel kills the process. If you cancel the
move, dolphin's memory usage stays the same and even after closing the whole
window, it stays in System Monitor, you need to end the process to actually
close it.
To reproduce, create a large file (maybe as root, not sure if that's needed):
1. dd if=/dev/urandom of=8BG.bin bs=64M count=124 iflags=fullblock
2. Open the folder containing it in dolphin with act as administrator
3. Move to another regular tab
4. Watch as memory usage rises and also the progress indicator stays on 0%
As a workaround, you can open the destination folder with act as administrator,
then the move is basically instant, and memory usage stays the same.
Some additional stuff:
Copy between 2 admin tabs works, but the indicator is 0% throughout
Copy from an admin tab to a regular tab works the same as moving
Moving from a regular tab to an admin tab is slow, it seems to copy it, however
the indicator works
Copying from a regular tab to an admin tab works as moving
If I cancel the copy or move, there is a file left called <original name>.part,
and if I don't remove it before doing a subsequent copy, it will not ask if I
want to override the existing file. If the .part file is not there, it will ask
if I want to override it. However, in this case, I don't think the copy/move
actually does anything, as the file sizes stay the same and the indicator is
stuck on 0% again.
Also, this bug report is probably related:
https://bugs.kde.org/show_bug.cgi?id=489926
--
You are receiving this mail because:
You are watching all bug changes.
