https://bugs.kde.org/show_bug.cgi?id=401088
--- Comment #50 from Steve Vialle <stev...@runbox.com> --- (In reply to SoftExpert from comment #48) > 1. the need for a better design of the KIO - UI interaction, making it > truly asynchronous Indeed. That, and the file manager and/or underlying frameworks _not_ attempting to access devices unrelated to the current view to begin with (which would address dolphins other persistent aggravation - it spins up and waits on all devices, even when the directory it's opening is not on those filesystems). > 2. potentially, NFS could be made to behave - by carefully selecting more > effective parameters. > > When NFS is better configured, since it can approach in a different way the > connection to network resources that are not yet available, KIO will have to > wait very little time, so it appears in the UI like a fast operation; when > NFS is badly configured or encounters a problem and, stubbornly, tries to > handle the issue in synchronous mode, KIO will wait for the result to become > available and will block the UI thread - and this is the part that can an > should be addressed by this bug. UI blocking bug, definitely. NFS "misbehaving"... Not so much. There is no badly configured NFS here, sync is the default for good reason and NFS blocks waiting for the server _by design_. Mounting NFS async will indeed reduce latency, but it will also cause it to lie to programs requesting sync writes and return before data is on stable storage, which can potentially cause data loss. Network filesystems can and often are high latency. Mechanical disks can be high latency if they're in standby or otherwise occupied. KDE simply should not be making the assumption that the whole "local" (system mounts and all) filesystem tree is going to be fast enough that it can get away with blocking UI threads while waiting on I/O... Especially when that blocking freezes not only the file manager window displaying an affected directory, but also _other_ dolphin instances, often along with parts of the desktop like the taskbar and notification system. If I attempt to enter the mountpoint of an unresponsive NFS export in a sane file manager (e.g. mc), that instance will likely freeze until the mount is available. That's not ideal, but it is expected and not a deal-breaker because it doesn't freeze my shell and I can continue using other instances of the file manager in other directories. Dolphin on the other hand will freeze if I open it in an *unrelated* directory (likely trying to populate the "places" panel and other fluff), as will any other new or existing dolphin instances, because they share a common framework. This is not reasonable behaviour by any stretch of the imagination, the primary job of a file manager is to operate on CWD, not crawl every possible mount on the system every time the user sneezes and go catatonic if it encounters anything that isn't on NVME. To be fair none of this really belongs here though, this bug report is specifically for misbehaviour of a recent "improvement" meant to [s]direct blame at the underlying filesystem[/s] inform the user as to why their file manager is hanging... I.e. addressing a symptom rather than the cause. Then again none of the other multiple reports attributable to this seem to be getting any attention either, so whatever. -- You are receiving this mail because: You are watching all bug changes.
