[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Andreas Sturmlechner changed: What|Removed |Added CC||ast...@gentoo.org -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #56 from Bug Janitor Service --- A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1718 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 soredake changed: What|Removed |Added CC|katyaberezy...@gmail.com| -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #55 from postix --- Question for those who can reproduce the issue: Is the issue fixed or improved by https://invent.kde.org/frameworks/kio/-/merge_requests/957 ? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 soredake changed: What|Removed |Added CC||ndrzj1...@relay.firefox.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REPORTED --- Comment #54 from Nate Graham --- Indeed, just because one person was experiencing faulty hardware, doesn't mean the legitimate issue in KDE software is fixed for everyone. I will hide the non-relevant comments. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #53 from ric...@nakts.net --- Any chance to hide the comments that deal with faulty hardware? They make the bugreport impossible to follow. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #52 from empyreal --- Seagate is to blame for everything. This is shit SMR technology. This drive needs brakes and smaller packs of data. It’s busy working for 10 min after huge copy process. After brake works faster, then slows down. And if you turn it off immediately, which on USB is common thing, it's internal program may go into some sort of loop or what. https://ubuntuforums.org/archive/index.php/t-2370055.html -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 empyreal changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #51 from empyreal --- It didn’t work out that easily, till I dd whole drive with zeros. Switching to SATA makes things easier, but... Drive started glitching again after copy canceling. dd with zeros took 11 hrs starting from 140 MB/s and finished with 95 MB/s. Then drive stopped slowing boot and restart. Formatted with AOMEI from USB stick. Copying very rarely drops to 200 KB/s, but generally ok - 388 GB in 3:20 hrs. Copied more than 1,5 TB already and continue. And now I do not need to Offline disk in Windows. It mounts rw on Kubuntu. smartctl -l devstat shows few things but no time when they happened: 0x03 0x030 4 1 --- Number of Mechanical Start Failures 0x03 0x038 4 0 --- Number of Realloc. Candidate Logical Sectors 0x04 0x008 4 1 --- Number of Reported Uncorrectable Errors Nick, your advice was to the point! Easiest thing to do - wiping with zeros and then move forward. “Low level format” helped me in the past with few drives, but in this case, as it was very long process and there were no bads or relocs, I thought dd MBR will be enough. Maybe this drive was glitching long time but I didn’t noticed on small data volumes and cancel operation triggered smth... My bad... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #50 from empyreal --- Seagate is to blame for supplying bad controllers for it’s USB drives? How to check that USB controller properly? I don’t want my 3.6 TB go into coma again. The only thing I can do, connect old 2.5” Seagate 80 GB and try to mess with it. Any decent utilities? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #49 from Nick --- For what's it's worth I think you have a bad USB controller, I've comes across plenty of poor quality USB controllers, not to mention an inadequate power supply that's supposed to power the drive. In fact I have several USB controllers that only work properly when I power the drive that's attached to USB with a ATX power supply, a lot depends on the drive power ratings. If I was you I'd throw that particular USB controller in the bin and buy a decent quality USB controller with lots of good reviews. Good luck, now you are using SATA, I'm sure everything will be fine ! I'm going to log off and stay quiet now as I don't really think this problem is solely related to KIO copying. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #48 from empyreal --- I read so many forums that I got bloodshot eyes. I wrote how it all started. Slow copy and laggy copy canceling in Krusader on perfectly working 3 years old USB drive. No glitch ever! I never ever experienced such issues on Windows. No slow copying or laggy copy canceling in Total Commander with USB drives. That’s was the reason to try cp in Konsole. Canceled cp in Konsole and got this... Just finished copying with Krusader 335 GB via SATA – 2,5 hrs. I think, now this drive works as it should. I have no inclination to mess with USB controller again and continue to use it as SATA. If it fails, I’ll give notice. I do not expect slow copy problem to be addressed anytime soon, actually I do not expect anything, but maybe this info will help in some way, whatever. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #47 from postix --- > I need to figure out whether it is hardware issue or not. empyreal, would you maybe like to discuss this first in a forum until you have ruled out that this is not a _disk_ issue on your side? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #46 from empyreal --- USB Seagate Backup Plus Drive. I tried copy in Konsole, because I noticed slow copy in Krusader. Copy canceling in Krusader was slow too. After I canceled cp process in Konsole, I got Partition 1 does not start on physical sector boundary. Fixed issue in GParted by reformatting. It also realigned automatically. Somehow “HDD reset” on Windows and started working properly. I thought that everything is ok and left it to copy whole night on Kubuntu. Speed dropped and mess started again. It’s interesting whether it is hardware fault or software fault leading to hardware fault. Slow copying to USB drive is common problem on Linux and it should be addressed properly. It’s unacceptable that server system has issues with data transfers. GParted drive again in vain. Made things worse on Windows. Strange manipulations on Windows and I noticed that drive became responsive again. Checked it with SeaTools once again. Populated volumes info. Drive works fast but copy sucks. Offline. Disconnected USB drive. Booted Kubuntu. Waited for USB drive to cool down. Connected drive. Mounted. Tried copying. Works as expected! Booted Windows. 1 MB/s. Booted Kubuntu again. Copy on 2-3 MB/s speed. Could not Remove safely… Shutdown. Removed drive from case. Never believe SeaTools... USB controller is OK. Checked with other Seagate drive. Connected HDD to SATA port. GParted messaging about errors. dd everything. Successfully formatted drive. Problems with mounting in Kubuntu. I could create files on it as sudo su only. chown chmod remount - no result, except now sudo su can’t create anything too. Windows boots very slow with the drive. Connected hot, but copying sucks. Drive clicks like it constantly is reading smth. It behaves like this after unsuccessful mounting on Kubuntu, after copying/canceling on Kubuntu and reboot or PC hard reset from Kubuntu. On Windows it stopped clicking after a while. Windows detects hard drive as removable, despite it is SATA now. I need to Offline it as USB to mount rw file system on Kubuntu. Now I have ST4000LM024-2AN17V which can write with 1 MB/s speed at best on Windows. Kubuntu first copy starts fast, the slows down to zero. Second copy almost zero speed. And what happens next!!! //All drives are SATA. Faulty drive ST4000LM024-2AN17V. I test and copy to it. //Just booted Kubuntu. No copying sudo hdparm -Tt /dev/sdc /dev/sdc: Timing cached reads: 23030 MB in 2.00 seconds = 11531.43 MB/sec Timing buffered disk reads: 48 MB in 3.04 seconds = 15.78 MB/sec //Started copy process in Krusader. Starts fast and slows down. /dev/sdc: Timing cached reads: 24952 MB in 2.00 seconds = 12494.70 MB/sec Timing buffered disk reads: 268 MB in 3.06 seconds = 87.55 MB/sec //Started copy process in Krusader. Worked as expected O_O //Started copy process in Krusader. Worked as expected O_O sudo hdparm -Tt /dev/sdc /dev/sdc: Timing cached reads: 22382 MB in 2.00 seconds = 11206.40 MB/sec Timing buffered disk reads: 176 MB in 3.01 seconds = 58.46 MB/sec //Started copy process in Krusader. Worked as expected. 20 GB in 4 min. O_O Now I have ST4000LM024-2AN17V copying properly on Kubuntu or not? Any ideas? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #45 from empyreal --- I know that my approach is unprofessional but what to do? There are plenty of tools in Windows to check SMART. It is ok. Also there are no surface or file errors. SeaTools gives me hint that smth is wrong with USB controller. 99% that when I remove HDD from case, it will work properly. But I need USB drive and check copy on Windows. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #44 from Nick --- You could also run smartmontools on the drive, you may have to plug it into a SATA internal connector or ESATA if you have one. For smartmontools to be able to access the drive as not all USB to SATA adapters support ATA pass through. Again ShredoS will confirm whether the controller supports ATA pass through. Smartmontools will tell you all about the general health of the drive. I don't know this but I'm assuming windows can also do this but as I don't use Windows I don't know that for sure. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #43 from Nick --- (In reply to empyreal from comment #42) > I need to figure out whether it is hardware issue or not. > It’s some sort of interface buffer problem, because changing settings in > Windows helped for short period of time. > > Windows. Mount slow. Copy slow. > Offline and disconnected drive. Waited few min. > Connected drive and Online. Mount slow. Copying slow. > Device Manager => Volumes => Populate. Data received but no help. Mount > slow. Copy slow. Very long Shutdown. > > Windows. Waited few min. Connected USB drive. Mount slow. Copy slow. > Noticed that folders, copied on Kubuntu open with lag. Formatted USB drive > just in case. Switched buffer settings in Windows. Sometimes it helped USB > drive to copy faster, but for short period of time. Speed was unstable. > > Made few Short DST of SAS-SCSI-FC until device passed in SeaTools. > Rescanned. USB 1394 showed up. Copy slow. > Disconnected drive. Restarted Windows. Connected drive. > Copying started fast, then became slow. > > Device Manager => Volumes => Populate. Volume data received. Copying became > faster. I have no idea how it works, but it shows some effect. > Started copying. Starts very slow and then goes fast. > > Reboot with USB drive. Stuck. Unplugged drive. Rebooted Windows. > Connected USB drive. Started copying video files in Total Commander. Started > fast then speed dropped to 1 MB/s. > > Now drive steadily behaves like this: when connected, starts fast copy, the > slows down to … KB/s. Drive slows boot and restart. That initial burst is actually normal, but dropping to 1MB/s is classic behaviour when you have a bad drive or controller that's generating I/O errors. The reason for the initial burst is that when the I/O writes first start, the operating system is filling the I/0 buffer in CPU RAM which it does very much quicker than sustained disc I/O then once there is no more space in memory you then see the true I/O speed and if you have a bad drive or controller you will see it drop way down. For a spinning disc I'd expect anything from 30MB-160MB/sec. SSD maybe 200-400MB/s. So say you have 8GB CPU memory you would expect to see that initial burst drop off after you had copied maybe 4-6GB of files. As you are seeing 1MB/s after the initial burst I would say you do seem to have a hardware fault. Like I mentioned earlier using ShredOS will confirm that. Assuming you have a backup of everything on that disk. By using ShredOS if you see the same effect i.e an initial burst (which is expected as explained above) but then it drops to 1MB/s that would confirm to me you have a hardware fault. Even on a 20 year old spinning disc you would see 20-35MB/s 30 seconds or so after that initial burst. However if you don't see 1MB/s but see a sustained throughput that is much higher, then you most likely have a software issue. Until you run ShredOS you won't be able to isolate the problem. I'd also do a grep on /var/log/ messages and also Windows event log to look for I/O errors. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #42 from empyreal --- I need to figure out whether it is hardware issue or not. It’s some sort of interface buffer problem, because changing settings in Windows helped for short period of time. Windows. Mount slow. Copy slow. Offline and disconnected drive. Waited few min. Connected drive and Online. Mount slow. Copying slow. Device Manager => Volumes => Populate. Data received but no help. Mount slow. Copy slow. Very long Shutdown. Windows. Waited few min. Connected USB drive. Mount slow. Copy slow. Noticed that folders, copied on Kubuntu open with lag. Formatted USB drive just in case. Switched buffer settings in Windows. Sometimes it helped USB drive to copy faster, but for short period of time. Speed was unstable. Made few Short DST of SAS-SCSI-FC until device passed in SeaTools. Rescanned. USB 1394 showed up. Copy slow. Disconnected drive. Restarted Windows. Connected drive. Copying started fast, then became slow. Device Manager => Volumes => Populate. Volume data received. Copying became faster. I have no idea how it works, but it shows some effect. Started copying. Starts very slow and then goes fast. Reboot with USB drive. Stuck. Unplugged drive. Rebooted Windows. Connected USB drive. Started copying video files in Total Commander. Started fast then speed dropped to 1 MB/s. Now drive steadily behaves like this: when connected, starts fast copy, the slows down to … KB/s. Drive slows boot and restart. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 empyreal changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REPORTED --- Comment #41 from empyreal --- Copied 379 GB from internal notebook drive to USB drive. Different files, mostly short videos. Process went successfully and took 4 hrs. Queued 783 GB from internal desktop HDD”. In 6 hrs it copied 535 GB and again stuck on mp3 (163 GB of mp3). Copying speed dropped to 2 MB/s which is strange: these are not tiny files. Assuming that average copying speed to USB 3.0 drive is 3 GB/min, these are still bad results. The only solution to make copying faster seems in queuing folders (F2 in Krusader), which is annoying pain in the ass, when you need just to copy all content from one drive to another. Paused copy process and drive became unresponsive. Can’t open anything on USB drive. Two CPU cores froze on 100% load. Krusader became unresponsive. Nothing can be done. Killed kioslave5 in System Monitor. Krusader became responsive. USB drive works too. Tried to copy 5 GB of jpegs. Very slow. 1 GB in 5 min. Cancelled. Krusader works, drive works. No freeze. Tried to copy 5 GB of mp3s. Same story. 1-2 MB/s. Reached target Reboot. Stuck. Reset. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Luis Miguel García Mancebo changed: What|Removed |Added CC|kte...@ktecho.com | -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 empyreal changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #40 from empyreal --- When there is dual boot, Offline USB drive in Windows Disk Management after use. Now USB drive mounts properly - rw. Moreover - it works properly! Copying goes as fast as on Windows and I feel dumb. But question remains: why Ctrl+C of cp process in Konsole created issue with USB drive? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #39 from empyreal --- Nick, thanks for help! It’s system problem. Krusader and cp worked same way. Why expect rsync work another way? I wrote that I got problem after canceling cp process in Konsole. I never had any problems with this drive, till I tried copying in Konsole. I was noticing sometimes that copying speed was slow, but I didn’t copy 200-300 GB to this USB drive, because all backups were done on Windows. I copied small volumes from time to time. I’ll test it again after I deal away with ro mount issue. I managed to awake USB drive from coma in Windows 10 with Device Manager (Populate function somehow worked out) and formatted drive in AOMEI, because Windows showed messages with errors. Now on Windows everything works as it should – 5 GB in 2 minutes! No issues with USB drive detection and mounting. On Kubuntu I still have mount problem. It always mounts USB drive as ro file system: drwxrwxrwx 1 user user 4096 sep 18 20:31 'Seagate Backup Plus Drive' /dev/sdc1 on /media/user/Seagate Backup Plus Drive type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) $ sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 /dev/sdc1 on /media/user/Seagate Backup Plus Drive type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) rw now but still I can’t copy or create files. It’s another issue, so I won’t flame here anymore. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #38 from Nick --- (In reply to empyreal from comment #37) > Copying finished. 5 GB transfer took almost 1hr O_O > > Reboot failed. Linux was stopping Disk Manager for 90 sec and failed. > Rebooting to Windows 10. Problems with loading drive. > Reboot failed. Reset. > Rebooting to Linux. > Can’t mount USB drive. > sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too > shutdown now > Started PC and booted Kubuntu. > Connected USB drive. > Partition 1 does not start on physical sector boundary. AGAIN!!! > Can’t mount in Krusader and Notifier. > sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too > Deleted partition. Formatted to NTFS. > Partition 1 does not start on physical sector boundary. GONE! > shutdown now > Started PC. Booted Kubuntu. > I am not authorized to mount device. No automount. > sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 WORKED!!! > Unmount in Notifier. > shutdown now > Started PC. Booted Kubuntu. > USB drive is not mounted automatically. > Notifier don’t show any messages. > > All that nonsense went on till Partition Manager reported that it can’t > create partition because of errors. I booted to Windows again and make all > necessary operations in AOMEI. Then booted to Linux and got Partition 1 does > not start on physical sector boundary. Installed GParted, reformatted > everything and got USB drive which mounts on Linux with read-only file > system and can’t mount on Windows anymore. > > I don’t know exactly what happened, but USB drive started working on Kubuntu > after I tried it on old notebook with Windows 7 where it didn't mount. > Booted Kubuntu. Then connected USB drive. At first it was automatically > detected like ro file system and then system redetected it again > automatically in new folder with rw files system. > > But now not only copying sucks in Krusader but Alt+Enter counts for > eternity. Now is hard to tell whether Linux sucks or USB drive sucks, but I > feel that USB controller on USB drive is glitchy, because even SeaTools on > Windows do not detect it at first try. > > Tried rsync but with 5 GB of images but it stuck after 2,5 GB as Krusader. > Cancelled and got one CPU core freezed with 100% load. > > That’s most annoying problem on Linux so far. Just simple cp canceling in > Konsole... I wasted 3 days, figured basically nothing and made things worse. > Last solution will be to open case and use external drive as internal. At > least I am sure that drive inside has standard ports. I've had very little problem with USB drives, I've been using KDE Neon for a few years now. Sounds like you have a hardware fault especially as rsync doesn't work either, I use rsync on a daily basis to check and copy thousands of files, never have a problem. If that was my system I'd probably wipe the drive with nwipe (ShredOS) https://github.com/PartialVolume/shredos.x86_64 , it will give you an idea of throughput and will check every block with verification. if that bombs out with an I/O error I'd test the drive on another system with a different USB controller in order to isolate the problem. If it's the drive scrap it, it's not worth the hassle. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #37 from empyreal --- Copying finished. 5 GB transfer took almost 1hr O_O Reboot failed. Linux was stopping Disk Manager for 90 sec and failed. Rebooting to Windows 10. Problems with loading drive. Reboot failed. Reset. Rebooting to Linux. Can’t mount USB drive. sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too shutdown now Started PC and booted Kubuntu. Connected USB drive. Partition 1 does not start on physical sector boundary. AGAIN!!! Can’t mount in Krusader and Notifier. sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 do not work too Deleted partition. Formatted to NTFS. Partition 1 does not start on physical sector boundary. GONE! shutdown now Started PC. Booted Kubuntu. I am not authorized to mount device. No automount. sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 WORKED!!! Unmount in Notifier. shutdown now Started PC. Booted Kubuntu. USB drive is not mounted automatically. Notifier don’t show any messages. All that nonsense went on till Partition Manager reported that it can’t create partition because of errors. I booted to Windows again and make all necessary operations in AOMEI. Then booted to Linux and got Partition 1 does not start on physical sector boundary. Installed GParted, reformatted everything and got USB drive which mounts on Linux with read-only file system and can’t mount on Windows anymore. I don’t know exactly what happened, but USB drive started working on Kubuntu after I tried it on old notebook with Windows 7 where it didn't mount. Booted Kubuntu. Then connected USB drive. At first it was automatically detected like ro file system and then system redetected it again automatically in new folder with rw files system. But now not only copying sucks in Krusader but Alt+Enter counts for eternity. Now is hard to tell whether Linux sucks or USB drive sucks, but I feel that USB controller on USB drive is glitchy, because even SeaTools on Windows do not detect it at first try. Tried rsync but with 5 GB of images but it stuck after 2,5 GB as Krusader. Cancelled and got one CPU core freezed with 100% load. That’s most annoying problem on Linux so far. Just simple cp canceling in Konsole... I wasted 3 days, figured basically nothing and made things worse. Last solution will be to open case and use external drive as internal. At least I am sure that drive inside has standard ports. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #36 from empyreal --- Trying to put my USB drive to normal working state. Booted Linux. Connected USB drive. Notifier said that I am not authorized to mount it, so USB drive didn’t mount automatically. I mount it with this command: sudo mount -o remount,uid=1000,gid=1000,rw /dev/sdc1 USB drive mounted. Started copying 5 GB of jpg files for testing purposes. Regretted. After 2.5 GB speed dropped to 256 KiB/s. Afraid to cancel copying, because it will definitely make HDD unresponsive again. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #35 from empyreal --- Reboot stuck. Made hard reset. Rebooted. Booting slowed dramatically both on BIOS phase and Linux HDD detecting phase. After reboot to Kubuntu, it can’t automount external USB drive. I can’t mount it in Notifier. After reboot to Windows, it can’t mount external USB drive. Shutdown PC. Disconnected and booted Kubuntu. Connected external USB after boot. It didn’t mount automatically and I can’t mount it manually in Notifier. Deleted partition in Partition Manager. After that reboot became normal. Booted to Windows. Formatted partition with AOMEI. Process was very slow, which is abnormal, but finished. This copy process in Linux definitely hurts external USB drive. Start copying same data in Windows with Total Commander and got same problem. Windows couldn’t shutdown with external USB drive. It looks like canceling copy process in Linux makes external USB drive unresponsive and reformatting, rebooting do not help. Problems with this external USB drive started after canceling cp in Konsole. After that I got some weird things with mounting. I was using this drive happily without any problems till that moment. I am going through this problem second time. Copy canceling is dangerous... -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #34 from empyreal --- https://superuser.com/questions/424512/why-do-file-copy-operations-in-linux-get-slower-over-time 10 years later… I cancelled this joke copying and it stuck two cores of my CPU on 100% and freezed Krusader. Before copying I didn’t have this message: Partition 1 does not start on physical sector boundary. sudo fdisk -l Disk /dev/sdb: 3,64 TiB, 4000787029504 bytes, 7814037167 sectors Disk model: BUP BK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: A601FD60-033F-4D1A-8E6C-BCEDD9D0D189 Device StartEndSectors Size Type /dev/sdb1 63 7814032063 7814032001 3,6T Microsoft basic data Partition 1 does not start on physical sector boundary. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #33 from Nick --- (In reply to empyreal from comment #31) > This problem persists. 362 GB of data. F5 list of folders in Krusader from > internal NTFS HDD to external NTFS USB 3.0 HDD. > > 40 GB were copied very fast – 20 min or so. 180 GB were copied slowly in 3hr > and I thought the rest 182 GB would be copied in 3hrs but it didn’t happen. > Almost 12 hrs passed, but it copied 270 GB. > 90 GB still to go according to copying status. > It’s definitely not OK. I feel your pain, while I love Dolphin, for me it's only capable of dealing with small amounts of data due to this 'grave' bug. And yes it is a grave bug for those that work with a lot of data. I generally use cp and rsync instead of dolphin for anything more than a few files. Having said that there is absolutely no reason why Dolphin should not be as fast as cp or rsync , we are talking I/O here, orders of magnitude slower than any CPU can operate at. The problem here is a bug or at least the way Dolphin does the copy. If that's correct that every time a file is copied some massive list is sorted then that's just not the way you do it. I only wish I could devote my time to fixing this problem. It's the one bug/feature in Dolphin that spoils an otherwise excellent program. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #32 from empyreal --- lsusb Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 0bc2:ab30 Seagate RSS LLC BUP BK Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 056a:033b Wacom Co., Ltd CTL-490 [Intuos Draw (S)] Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub lsusb -t /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 1M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 1M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/8p, 1M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M |__ Port 13: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 13: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 13: Dev 2, If 2, Class=Human Interface Device, Driver=usbhid, 12M -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 empyreal changed: What|Removed |Added Status|CONFIRMED |REPORTED Ever confirmed|1 |0 --- Comment #31 from empyreal --- This problem persists. 362 GB of data. F5 list of folders in Krusader from internal NTFS HDD to external NTFS USB 3.0 HDD. 40 GB were copied very fast – 20 min or so. 180 GB were copied slowly in 3hr and I thought the rest 182 GB would be copied in 3hrs but it didn’t happen. Almost 12 hrs passed, but it copied 270 GB. 90 GB still to go according to copying status. It’s definitely not OK. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 empyreal changed: What|Removed |Added CC||empyr...@ukr.net --- Comment #30 from empyreal --- I have similar issue copying to external 3.6TB USB3.0 NTFS drive in Krusader. 362 GB of data. Different files: music, video, pictures, text… It couldn’t copy this information volume during whole night O_o Now I reformatted drive in NTFS with default cluster size without any additional parameters. Before drive was formatted by vendor and had additional small partition at the beginning. At first copying started with 100MB/s and after 40 GB speed dropped to 0,5-2 MB/s while copying mp3 files. Speed is very unstable. Sometimes jumps to 30-60 MB/s, then drops to 0,5-2 MB/s. It copies better after formatting, but is it OK? Operating System: Kubuntu 21.04 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.11.0-34-generic (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Safeer Pasha changed: What|Removed |Added CC||safeerpas...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Salvatore changed: What|Removed |Added CC||sannythebes...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Patrick Silva changed: What|Removed |Added CC||bug@petzel.at --- Comment #29 from Patrick Silva --- *** Bug 428073 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Postix changed: What|Removed |Added CC||pos...@posteo.eu -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #28 from Méven Car --- Git commit 10cf5aca5b3da2608eaf2967415d0b09b36121ac by Méven Car. Committed on 04/04/2020 at 18:52. Pushed by meven into branch 'master'. File ioslave : use Better setting for sendfile syscall Summary: Changes : * use sendfile when copying file bigger than 2 GB * copy 512 kB instead of previously 32 kB for each sendfile or read/write copying iteration This effectively increase the copying speed, since the filesystem is asked to copy more at once, it lets it reach higher speed before getting the next data to copy. Related: bug 402276 Test Plan: Copying large files or folders with medium sized files (for instance photos) is noticebly faster. Reviewers: #frameworks, dfaure Reviewed By: dfaure Subscribers: bruns, broulik, kde-frameworks-devel Tags: #frameworks Maniphest Tasks: T11627 Differential Revision: https://phabricator.kde.org/D28555 M +3-5src/ioslaves/file/file_unix.cpp https://commits.kde.org/kio/10cf5aca5b3da2608eaf2967415d0b09b36121ac -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added Priority|NOR |HI -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=339830 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Alexander Potashev changed: What|Removed |Added CC||aspotas...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 alex...@gmx.net changed: What|Removed |Added CC||alex...@gmx.net -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added CC||kte...@ktecho.com --- Comment #27 from Nate Graham --- *** Bug 396093 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nick changed: What|Removed |Added CC||nick.craig@gmail.com --- Comment #26 from Nick --- Hmmm, I've just posted what sounds like the same problem here https://bugs.kde.org/show_bug.cgi?id=393748 I've added attachments showing the debug output of the plasma-shell threads and dolphin threads. Hope it is useful. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added CC||ka...@seznam.cz --- Comment #25 from Nate Graham --- *** Bug 203277 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 karaluh changed: What|Removed |Added CC|kara...@karaluh.pl | -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added CC||kara...@karaluh.pl --- Comment #24 from Nate Graham --- *** Bug 304136 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Simon Andric changed: What|Removed |Added CC||simonandr...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 David M changed: What|Removed |Added CC||davidmarch...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #23 from Jaime Torres --- Git commit e1fe26f1fc78082fdb215cb818177541d4607d9c by Jaime Torres. Committed on 19/02/2018 at 20:09. Pushed by jtamate into branch 'master'. Reduce plasmashell frozen time to almost nothing Summary: Related: bug 358231 Even the icon with the number of tasks pending moves from time to time. To reduce the frozen time, a similar patch must be applied also to frameworks/kwindowsystem src/platforms/xcb/kxmessages.cpp frameworks/plasma-framework src/plasma/private/effectwatcher.cpp According to the documentation (and a look to the source code) http://doc.qt.io/qt-5/qabstractnativeeventfilter.html The type of event eventType is specific to the platform plugin chosen at run-time, and can be used to cast message to the right type. On X11, eventType is set to "xcb_generic_event_t", and the message can be casted to a xcb_generic_event_t pointer. The other eventType are "windows_generic_MSG" and "mac_generic_NSEvent". No other eventType starts with an 'x'. Test Plan: Cut & paste 2000 small files. Before, a freeze (plasmashell not responding) of minutes After, a freeze of seconds Reviewers: #frameworks, #plasma, davidedmundson Reviewed By: #plasma, davidedmundson Subscribers: broulik, davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D10627 M +1-1shell/screenpool.cpp https://commits.kde.org/plasma-workspace/e1fe26f1fc78082fdb215cb818177541d4607d9c -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Philippe Didier changed: What|Removed |Added CC||philippedid...@laposte.net --- Comment #22 from Philippe Didier --- I don't know if it would be useful for this bug but I got some problems with Dolphin (Mageia 6, KF5 16.12.3 Dolphin 16.12.3 plasma 5.8.7) It seems that Dolphin doesn't work always the same way for ntfs partitions on USB external disk: It depends on the way this partition is mounted : 1) if it is mounted with fstab (in this case it apparently DOES NOT USE udisks2) we can explore the content on the mout point choosen in fstab but it freezes eating CPU with mout.ntfs-3g and gam_server Dolphin is quite unresponsive when exploring a huge folder containing subfolders with thousands of photos 2) if it is an hotplugged partition (in this case it seems to use udisks2) a notification pop-up proposes to use Dolphin and it is OK : we explore it in /run/media/username/hddname (mount-ntfs-3g and gam_server use CPU for 3 seconds) and we get no freeze exploring the same NTFS partition https://bugs.mageia.org/show_bug.cgi?id=7985#c12 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #21 from Jaime Torres --- Oh!, I misread the data. The file operations are fast, but plasma is still showing information about half the files when the files operations has already concluded. (This could be easier to improve than the lock and could reduce the lock time). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #20 from Jaime Torres --- The performance improvements apply also to the problem with several thousands of files in several directories. Just to be sure, I've checked a harder test case (50.000 little files in several directories) and the performance improvements apply, but there is still room for improvement, because after moving 25.000 files, the performance drops. The problem with plasma being locked is still pending, but we are working on it. As you can see, it is not an easy bug to fix. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #19 from Kevin Kofler --- The reporter wrote: (Alexander Nestorov from comment #5) > I copy the entire folder, without getting inside it. but as far as I can tell, your optimizations are all only addressing the case where somebody selects many individual files and drags&drops them somewhere as a group, not the case the reporter described (a recursive copy of one single folder that just happens to contain many small files inside). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #18 from Jaime Torres --- Git commit 9fbf7a0b624aee6b116efdf69462e73f0275fab6 by Jaime Torres. Committed on 05/02/2018 at 18:25. Pushed by jtamate into branch 'master'. Faster drag&drop in directories with thousands of files Summary: The check is called when the mouse is moved in a drag&drop operation. Dragging all files in a directory with 3000 files under callgrind, moving the mouse to the other panel and then canceling, doing it twice, callgrind shows that the method urlListMatchesUrl is called around 200 times, spending around 9,30% of the cpu in those calls. Applying the patch, callgrind tells it uses now 0.31% of the cpu in 1208 calls. Reviewers: #dolphin, elvisangelaccio, markg Reviewed By: #dolphin, elvisangelaccio, markg Subscribers: markg, anthonyfieroni, michaelh, elvisangelaccio, ngraham Differential Revision: https://phabricator.kde.org/D10085 M +3-0src/kitemviews/kitemlistcontroller.cpp M +17 -3src/views/draganddrophelper.cpp M +10 -0src/views/draganddrophelper.h https://commits.kde.org/dolphin/9fbf7a0b624aee6b116efdf69462e73f0275fab6 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #17 from Jaime Torres --- Git commit 18e4d245d3d595cdc17ad40aa88495d6d2c30bf7 by Jaime Torres. Committed on 28/01/2018 at 11:01. Pushed by jtamate into branch 'master'. Use the much faster urls() method from QMimeData Summary: When requesting a list of text/uri-list, use the much faster QMimeData urls() method. The unittests pass (the desktop: protocol) and is half solved. The paste speed is as fast as drag&drop in local files and with fish: files. The lock in X11 plasma or kwin still needs another patch. Test Plan: Select 2000 files in one folder, cut and paste them in another disk. Reviewers: #frameworks, dfaure Reviewed By: dfaure Tags: #frameworks Differential Revision: https://phabricator.kde.org/D10155 M +6-3src/lib/io/kurlmimedata.cpp https://commits.kde.org/kcoreaddons/18e4d245d3d595cdc17ad40aa88495d6d2c30bf7 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 aux...@gmail.com changed: What|Removed |Added CC||aux...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #16 from Nate Graham --- Thanks, that's hugely helpful! We're actively investigating this, BTW. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #15 from Dr. Chapatin --- I did some tests on Arch Linux running plasma 5.12 beta and dolphin 17.12.1. Always copying/moving a folder containing 104.607 small files and 1.678 subfolders (889 MiB) from a hard disk to another hard disk, both formatted with NTFS file system. copy using ctrl+c/ctrl+v: completed in 9 minutes copy using "copy" and "paste" from dolphin context menu: completed in 11 minutes move using ctrl+x/ctrl+v: completed in 72 minutes move using "cut" and "paste" from dolphin context menu: completed in 158 minutes (???) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #14 from Nate Graham --- For people experiencing this, how are you doing the copy? copy-paste? drag-and-drop? Does it happen for both methods, or just one? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added CC||jtam...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 --- Comment #13 from Dr. Chapatin --- This old bug makes dolphin unusable to deal with high amount of small files. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 342056] Ridiculously slow file copy (multiple small files)
https://bugs.kde.org/show_bug.cgi?id=342056 Nate Graham changed: What|Removed |Added Product|kio |frameworks-kio Version|4.14.1 |5.42.0 CC||kdelibs-b...@kde.org Component|general |general -- You are receiving this mail because: You are watching all bug changes.