Bug 342056 - Ridiculously slow file copy (multiple small files)
Summary: Ridiculously slow file copy (multiple small files)
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.42.0
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords: usability
: 203277 304136 389296 396093 428073 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-12-20 18:37 UTC by Alexander Nestorov
Modified: 2022-09-14 17:00 UTC (History)
23 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Nestorov 2014-12-20 18:37:31 UTC
I'm assigning this to Dolphin, but I'm not really sure if this should be assigned to Dolphin or KIO or any other component. Feel free to changed it to whatever component you think is better.

The problem is that copying a 15GB folder with small files (thumbnails, ~20-40 kb each file) will:

a) be ridiculously slow. Where talking about a +20x difference in times, compared to rsync. rsync will take around 20 minutes to copy that amount of data, while KDE takes several hours (5-6, even 10).

b) the entire desktop (or maybe just plasma and all KDE-related stuff?) gets completely laggy/unreasonably slow. Even things as simple as moving the mouse pointer feels slow (the mouse pointer jumps from one location to another). Note that this doesn't happen with rsync.

The CPU usage in both cases is more or less the same, around 30% to 50%. The CPU is a i7-3820 @ 3,6Ghz
I'm on EXT4, and the drive isn't damaged, I can completely asure this (no errors in SMART, ran a few bad-sectors detectors liveCDs, everything is fine). The HDD is a Western Digital WD Blue WD5000AAKS 500GB 16MB Cache SATA 3.0Gb/s 3.5". This is what 'lshw' says about it:

configuration: created=2014-04-12 16:46:46 filesystem=ext4 lastmountpoint=/home modified=2014-12-13 12:58:29 mount.fstype=ext4 mount.options=rw,relatime,data=ordered mounted=2014-12-13 12:58:29 state=mounted

The MB is an Intel DX79SI.

Reproducible: Always

Steps to Reproduce:
1. Create a 15GB folder with subfolders and small files (20-40 kb each file)
2. Copy the entire folder
3. Watch your entire desktop lag.

Actual Results:  
The desktop is laggy and the copy process is slow.

Expected Results:  
The desktop should stay responsive and the file progress should be hitting the HDD's limits instead of hitting who-knows-what-bug in KDE which is making the progress slow.

I'm leaving this as "Grave" because this is something that shouldn't be happening in such a mature DE and because this bug is making my machine unusable (while copying files).

I agree that "I'm copying a 15GB of thumbnails" is not a common case, but regardless whether it's a common case or not, there is clearly something broken in KDE (or Dolphin or KIO or XYZ component).
Comment 1 Christoph Feck 2014-12-20 19:39:53 UTC
Can you please check the performance of "kioclient copy src dest" on your system? I doubt it is a Dolphin issue.
Comment 2 Alexander Nestorov 2014-12-22 00:27:00 UTC
Yes, sorry for the delay. I'll test it tomorrow evening.
Comment 3 Alexander Nestorov 2014-12-22 20:45:04 UTC
I tested everything again, and couldn't reproduce the second bug anymore. Now the system is quite responsive. Anyways, the first bug (slow copy) is still there, both with Dolphin copy and with kioclient copy.

Should I open another bug?
Comment 4 Frank Reininghaus 2014-12-28 23:03:45 UTC
Just to be sure, do you copy a folder which contains lots of files, or do you copy the files individually? I.e., do you select a single (but very large) folder and copy it, or do you enter the folder, select all files and then copy them? Moreover, could you tell us the exact number of files, and, if they are not in one directory, roughly how they are distributed in the directory tree?

I can confirm that copying lots of individual files is *extremely* slow and tried to investigate that with poor-man's-profiling. I usually get backtraces like the one below. Looking at KDirListerCache::findByUrl shows that it scans the (unsorted) list of KFileItems until the URL is found, so the runtime has a quadratic dependence on the number of files that are copied, which is problematic if that number is very large.

It's probably not trivial to fix this. One could use a QHash to provide O(1) lookup for URLs, but this would require a lot of memory and CPU cycles in large directories. An alternative would be to sort the KFileItems in the list by their URLs. This would provide O(log N) lookup without any additional memory requirements, but would require some overhead for sorting whenever items are inserted or modified.

(gdb) bt
#0  0x00007ffff297b57a in QUrl::QUrl(QUrl const&) (this=0x7fffffffc770, other=...) at io/qurl.cpp:4267
#1  0x00007ffff2ef6755 in KUrl::KUrl(KUrl const&) (this=0x7fffffffc770, _u=...)
    at /home/kde-devel/kde/src/kde/kdelibs/kdecore/io/kurl.cpp:490
#2  0x00007ffff59f8875 in KFileItem::url() const (this=0x497b260) at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/kfileitem.cpp:1548
#3  0x00007ffff59ccf9a in KDirListerCache::findByUrl(KDirLister const*, KUrl const&) const (this=0xbeaca0, lister=0x0, _u=...)
    at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/kdirlister.cpp:836
#4  0x00007ffff59ccba1 in KDirListerCache::itemForUrl(KUrl const&) const (this=0xbeaca0, url=...)
    at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/kdirlister.cpp:782
#5  0x00007ffff59d93b0 in KDirLister::cachedItemForUrl(KUrl const&) (url=...)
    at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/kdirlister.cpp:2785
#6  0x00007ffff597dbd1 in KIO::CopyJobPrivate::statCurrentSrc() (this=0xa5b4090)
    at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/copyjob.cpp:738
#7  0x00007ffff597d5d8 in KIO::CopyJobPrivate::statNextSrc() (this=0xa5b4090)
    at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/copyjob.cpp:696
#8  0x00007ffff597c6dc in KIO::CopyJobPrivate::sourceStated(KIO::UDSEntry const&, KUrl const&) (this=0xa5b4090, entry=..., sourceUrl=...) at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/copyjob.cpp:482
#9  0x00007ffff5986d54 in KIO::CopyJob::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (_o=0xa5b4240, _c=QMetaObject::InvokeMetaMethod, _id=19, _a=0xa64be00) at /home/kde-devel/kde/build/kde/kdelibs/kio/copyjob.moc:108
#10 0x00007ffff29ef869 in QMetaCallEvent::placeMetaCall(QObject*) (this=0xa65d920, object=0xa5b4240) at kernel/qobject.cpp:524
#11 0x00007ffff29f0aed in QObject::event(QEvent*) (this=0xa5b4240, e=0xa65d920) at kernel/qobject.cpp:1222
#12 0x00007ffff3a2662e in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=0x642a30, receiver=0xa5b4240, e=0xa65d920)
    at kernel/qapplication.cpp:4565
#13 0x00007ffff3a23bca in QApplication::notify(QObject*, QEvent*) (this=0x7fffffffdb00, receiver=0xa5b4240, e=0xa65d920)
    at kernel/qapplication.cpp:3947
Comment 5 Alexander Nestorov 2014-12-29 02:07:53 UTC
I copy the entire folder, without getting inside it.

Exact size of the folder (it's bigger now, but the bug is exactly the same): 48054231169 == 44,8GiB
Total number of files: 3050371
Total number of folders inside: 16285

Output of tree -d -L 3 media/ | xclip:

media/
├── avatar
│   └── 0001
│       ├── 01
│       ├── 02
│       ├── 03
│       ├── 04
│       ├── 05
│       ├── 06
│       ├── 07
│       ├── 08
│       ├── 09
│       ├── 10
│       ├── 11
│       ├── 12
│       ├── 13
│       ├── 14
│       ├── 15
│       ├── 16
│       ├── 17
│       ├── 18
│       ├── 19
│       ├── 20
│       ├── 21
│       ├── 22
│       ├── 23
│       ├── 24
│       └── 25
├── blog
│   └── 0001
│       └── 01
└── default
    └── 0001
        ├── 01
        ├── 02
        ├── 03
        ├── 04
        ├── 05
        ├── 06
        ├── 07
        ├── 08
        ├── 09
        ├── 10
        ├── 11
        ├── 12
        ├── 13
        ├── 14
        ├── 15
        ├── 16
        ├── 17
        ├── 18
        ├── 19
        ├── 20
        ├── 21
        ├── 22
        ├── 23
        ├── 24
        └── 25

57 directories


Each one of the folders at level 3 has many folders, with names like this one: "ff6b907341d5e6ce81704fdb8ef29b2e98e1703d_zoom".

I think you're over-engineering the entire thing. Have a look how "cp" or "rsync" are doing it. They both are small tools and they do it just fine.
Comment 6 Frank Reininghaus 2014-12-29 12:15:25 UTC
Thanks for the quick reply and for the additional information.

I do agree that there is some potential for optimization, but the "over-engineering" is not quite as pointless as it may seem at first sight. Note that KIO and the applications that use it are not just replacements for the command-line tools which mostly work on local directories. They can be used for accessing lots of different protocols (like ftp, smb, webdav, tar, zip, and many, many more), and the code that copies files works exactly the same for all of them. The actual access to the files and folders is done by kioslaves, i.e., external processes which abstract the characteristics of the different protocols away. Moreover, KIO tries to make sure that views in Dolphin or elsewhere which show the URL where files are modified are updated even if the protocol does not support directory watching. Therefore, it will never be possible to just do what cp or rsync do. A certain amount of overhead will always be there (but as I said, I do agree that there is too much overhead in some situations, and it makes sense to investigate ways to reduce it).
Comment 7 Dawit Alemayehu 2014-12-30 21:12:41 UTC
(In reply to Frank Reininghaus from comment #4)
> Just to be sure, do you copy a folder which contains lots of files, or do
> you copy the files individually? I.e., do you select a single (but very
> large) folder and copy it, or do you enter the folder, select all files and
> then copy them? Moreover, could you tell us the exact number of files, and,
> if they are not in one directory, roughly how they are distributed in the
> directory tree?
> 
> I can confirm that copying lots of individual files is *extremely* slow and
> tried to investigate that with poor-man's-profiling. I usually get
> backtraces like the one below. Looking at KDirListerCache::findByUrl shows
> that it scans the (unsorted) list of KFileItems until the URL is found, so
> the runtime has a quadratic dependence on the number of files that are
> copied, which is problematic if that number is very large.
> 
> It's probably not trivial to fix this. One could use a QHash to provide O(1)
> lookup for URLs, but this would require a lot of memory and CPU cycles in
> large directories. An alternative would be to sort the KFileItems in the
> list by their URLs. This would provide O(log N) lookup without any
> additional memory requirements, but would require some overhead for sorting
> whenever items are inserted or modified.

And that sorting is going to be expensive as the list grows. I have a simple test program that tests lookup in a QList with 50 million QString entries and running that on my monster of a machine results in the following:

********* Start testing of TestBenchmark *********
Config: Using QtTest library 5.4.0, Qt 5.4.0 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.2)
QDEBUG : TestBenchmark::initTestCase() LOOKUP: INDEX= 7898741 , ITEM AT INDEX= "Entry-48903726" , TOTAL ITEMS= 50000000
PASS   : TestBenchmark::initTestCase()

PASS   : TestBenchmark::indexBasedLookup()
RESULT : TestBenchmark::indexBasedLookup():
     379 msecs per iteration (total: 379, iterations: 1)

PASS   : TestBenchmark::forEachBasedLookup()
RESULT : TestBenchmark::forEachBasedLookup():
     437 msecs per iteration (total: 437, iterations: 1)

PASS   : TestBenchmark::iteratorBasedLookup()
RESULT : TestBenchmark::iteratorBasedLookup():
     378 msecs per iteration (total: 378, iterations: 1)

PASS   : TestBenchmark::constIteratorBasedLookup()
RESULT : TestBenchmark::constIteratorBasedLookup():
     366 msecs per iteration (total: 366, iterations: 1)

PASS   : TestBenchmark::concurrencyBasedLookup()
RESULT : TestBenchmark::concurrencyBasedLookup():
     382 msecs per iteration (total: 382, iterations: 1)

PASS   : TestBenchmark::sortList()
RESULT : TestBenchmark::sortList():
     9,237 msecs per iteration (total: 9,237, iterations: 1)

PASS   : TestBenchmark::binaryFindBasedLookup()
RESULT : TestBenchmark::binaryFindBasedLookup():
     0.00017 msecs per iteration (total: 94, iterations: 524288)
PASS   : TestBenchmark::cleanupTestCase()

Totals: 9 passed, 0 failed, 0 skipped, 0 blacklisted
********* Finished testing of TestBenchmark *********

Notice that it takes a huge amount of time (9 secs) to sort such a large list and that would have to happen each time someone inserts a new record.
Comment 8 Alexander Nestorov 2015-02-02 02:20:41 UTC
Can I get this bug in a "Confirmed" state?
Comment 9 Frank Reininghaus 2015-02-03 22:05:07 UTC
(In reply to Dawit Alemayehu from comment #7)
> Notice that it takes a huge amount of time (9 secs) to sort such a large
> list

But the sorting has to be done in the application that uses KDirLister anyway (at least if "Sort by Name" is used, which is true most of the time, I think). And if the user tries to open a directory with 50 million files, then there might be things that take even longer than 9 seconds of sorting in KDirListerCache ;-) 

> and that would have to happen each time someone inserts a new record.

You don't have to sort the entire list every time a new record (or some more new records) are inserted. One would first sort the new records, and then merge the two sorted lists (old and new records). For a single new file, one could just do a binary search to find the correct place in the list, which should be quite fast.

BTW, if many files are deleted in a folder with 50 million files, then I guess that looking these up in the unsorted list that we currently have would be a huge problem. With a sorted list, it could be done quite efficiently.

Maybe I'll try to analyze this in more detail when I find some time.

(In reply to Alexander Nestorov from comment #8)
> Can I get this bug in a "Confirmed" state?

I haven't analyzed the problem (which is different from the problem which I first thought you meant and which I discussed with Dawit) in detail yet, so I can't really say how bad it is and if it should be considered a bug or rather wishlist material (I'll let others decide that). 

It's definitely not "grave" though in my opinion. You've said yourself that "this is not a common use case"! And a factor of 20 in the performance between KIO and rsync does not really sound that bad to me. I have seen performance issues that were *much* worse. Moreover, you cannot really compare rsync to KIO because both are designed to do quite different things. I do agree though that any optimizations in KIO would be welcome.
Comment 10 richlv 2016-01-19 23:12:44 UTC
i've reported bug #358231 with somewhat similar symptoms, but they seemed to be different enough to warrant a new report
Comment 11 Alex Bikadorov 2016-11-01 17:43:02 UTC
I have a similar problem with KF 5.27.0, but only when moving files.
Tested with 1000 empty files on local fs (ext4, normal hd):

$time mv 1000_files/* 1000_files_temp/

real    0m0.028s
user    0m0.017s
sys     0m0.010s

$time kioclient move 1000_files/* 1000_files_temp/

real    1m44.809s
user    0m1.407s
sys     0m0.263s

Copy and delete works fine.

Doing the same in Dolphin causes similar behaviour (Bug #358231, as already mentioned): Moving the files is fast but the plasma workspace freezes up after it for over 5 minutes. Dolphin itself and all applications are responsive.
Comment 12 Nate Graham 2018-01-22 00:44:53 UTC
*** Bug 389296 has been marked as a duplicate of this bug. ***
Comment 13 Patrick Silva 2018-01-22 01:05:21 UTC
This old bug makes dolphin unusable to deal with high amount of small files.
Comment 14 Nate Graham 2018-01-24 20:59:30 UTC
For people experiencing this, how are you doing the copy?

copy-paste?
drag-and-drop?

Does it happen for both methods, or just one?
Comment 15 Patrick Silva 2018-01-25 03:20:34 UTC
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 (???)
Comment 16 Nate Graham 2018-01-25 14:13:55 UTC
Thanks, that's hugely helpful! We're actively investigating this, BTW.
Comment 17 Jaime Torres 2018-01-28 11:02:02 UTC
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    -3    src/lib/io/kurlmimedata.cpp

https://commits.kde.org/kcoreaddons/18e4d245d3d595cdc17ad40aa88495d6d2c30bf7
Comment 18 Jaime Torres 2018-02-05 18:26:04 UTC
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    -0    src/kitemviews/kitemlistcontroller.cpp
M  +17   -3    src/views/draganddrophelper.cpp
M  +10   -0    src/views/draganddrophelper.h

https://commits.kde.org/dolphin/9fbf7a0b624aee6b116efdf69462e73f0275fab6
Comment 19 Kevin Kofler 2018-02-06 03:34:03 UTC
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).
Comment 20 Jaime Torres 2018-02-06 07:27:16 UTC
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.
Comment 21 Jaime Torres 2018-02-06 08:13:34 UTC
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).
Comment 22 Philippe Didier 2018-02-16 12:48:01 UTC
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
Comment 23 Jaime Torres 2018-02-19 20:10:02 UTC
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    -1    shell/screenpool.cpp

https://commits.kde.org/plasma-workspace/e1fe26f1fc78082fdb215cb818177541d4607d9c
Comment 24 Nate Graham 2018-04-16 20:34:31 UTC
*** Bug 304136 has been marked as a duplicate of this bug. ***
Comment 25 Nate Graham 2018-04-25 21:58:21 UTC
*** Bug 203277 has been marked as a duplicate of this bug. ***
Comment 26 Nick 2018-05-01 23:53:30 UTC
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.
Comment 27 Nate Graham 2018-07-13 20:19:35 UTC
*** Bug 396093 has been marked as a duplicate of this bug. ***
Comment 28 Méven Car 2020-04-04 18:52:45 UTC
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    -5    src/ioslaves/file/file_unix.cpp

https://commits.kde.org/kio/10cf5aca5b3da2608eaf2967415d0b09b36121ac
Comment 29 Patrick Silva 2020-10-22 09:53:31 UTC
*** Bug 428073 has been marked as a duplicate of this bug. ***
Comment 30 empyreal 2021-09-17 18:28:49 UTC Comment hidden (spam)
Comment 31 empyreal 2021-09-18 05:12:22 UTC Comment hidden (spam)
Comment 32 empyreal 2021-09-18 06:20:24 UTC Comment hidden (spam)
Comment 33 Nick 2021-09-18 08:15:16 UTC Comment hidden (spam)
Comment 34 empyreal 2021-09-18 09:34:57 UTC Comment hidden (spam)
Comment 35 empyreal 2021-09-18 09:36:19 UTC Comment hidden (spam)
Comment 36 empyreal 2021-09-18 10:00:22 UTC Comment hidden (spam)
Comment 37 empyreal 2021-09-18 19:24:16 UTC Comment hidden (spam)
Comment 38 Nick 2021-09-18 21:08:01 UTC Comment hidden (spam)
Comment 39 empyreal 2021-09-18 21:29:33 UTC Comment hidden (spam)
Comment 40 empyreal 2021-09-18 22:48:28 UTC Comment hidden (spam)
Comment 41 empyreal 2021-09-19 10:52:51 UTC Comment hidden (spam)
Comment 42 empyreal 2021-09-19 12:47:42 UTC Comment hidden (spam)
Comment 43 Nick 2021-09-19 13:18:45 UTC Comment hidden (spam)
Comment 44 Nick 2021-09-19 13:42:23 UTC Comment hidden (spam)
Comment 45 empyreal 2021-09-19 15:56:12 UTC Comment hidden (spam)
Comment 46 empyreal 2021-09-20 09:56:31 UTC Comment hidden (spam)
Comment 47 postix 2021-09-20 11:00:33 UTC Comment hidden (spam)
Comment 48 empyreal 2021-09-20 12:10:23 UTC Comment hidden (spam)
Comment 49 Nick 2021-09-20 13:09:15 UTC Comment hidden (spam)
Comment 50 empyreal 2021-09-20 13:51:41 UTC Comment hidden (spam)
Comment 51 empyreal 2021-09-22 11:08:27 UTC Comment hidden (spam)
Comment 52 empyreal 2021-09-22 18:12:53 UTC Comment hidden (spam)
Comment 53 richlv 2021-09-22 18:38:30 UTC Comment hidden (spam)
Comment 54 Nate Graham 2021-09-22 18:44:27 UTC Comment hidden (spam)
Comment 55 postix 2022-09-14 17:00:58 UTC
Question for those who can reproduce the issue: Is the issue fixed or improved by https://invent.kde.org/frameworks/kio/-/merge_requests/957 ?