Thunar often slows down to a crawl when handling network shares (sftp:// in my example) a) Selecting a local file and dropping it into the remote thunar window sometimes cancels the dragndrop action. I actually have to hover the pointer with mouse1 pressed over the remote window and wait until it changes to the copy icon before I let go. b) Sometimes, copy operations to remote machines don't spawn any dialog. The remote Thunar window usually freezes and I can tell that my uplaod bandwidth is saturated, but I can't see what it is doing until it is done.
Created attachment 6009 Dialog spawned, no progress bar Here is another example trying to move something onto an sftp location. A dialog is actually spawned, but no progress bar is shown. The system monitor in the background proves that the operation is already in progress tho!
gvfs problem very likely, not much thunar can do about it.
(In reply to Harald Judt from comment #2) > gvfs problem very likely, not much thunar can do about it. Mhh. Are you sure? I'm not saying that GVFS is perfect, but... I would attribute a slow GUI to the Thunar. When I hover with a dragged file over a Thunar window and the cursor takes several seconds to turn into a copy icon, that really looks like an issue with Thunar's GUI. If that is indeed GVFS blocking the GUI, then wouldn't it be a good idea to transfer GVFS into an async thread to prevent such problems? Imo, a GUI application should never reject or considerably delay GUI operations (see drag'n'drop example above) just because some underlying component is slow.
I cannot reproduce this, though I agree there are faster methods than some GIO backends. Your issue might depend very much on the network speed, though. The reading is already done async. Maybe you can find out where it loses performance in the code, and whether it is really the GUI that "blocks"?
I've tried to reproduce it over the last few days. Here's what I have so far: - Both problems described in the bug description are related, they appear together or not at all. - Thunar works well with gvfs most of the time, then suddenly this bug triggers and it becomes problematic. I've yet to figure out what the trigger is. It happens seemingly randomly. - Network speed is not a factor. In fact, I can switch off the network entirely after connecting and (unless this bug has been triggered) encounter none of the problems described. Harald, do you have any ideas how I could diagnose this? I don't think it's practical to run Thunar in a debugger for days until this bug triggers again at some point.
I encountered this bug report from this forum post: <https://forum.xfce.org/viewtopic.php?id=9591>. My issue does not exactly match the description of this bug, but does exactly match the description of the linked forum post. When I drag-and-drop, or copy-paste a file into a gvfs folder (in my case, cifs) that thunar is currently viewing, the transfer runs at about 500KB/s. When I copy a file into a folder thunar is not currently viewing (by dragging onto a folder, or "paste into folder") the transfer runs at my full link speed. I know this is not the exact same as haarp's, but since I got here from that forum post and they are somewhat related, I figured it's better to post here than open a new bug. If this warrants its own bug report I'd be happy to make one.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/thunar/-/issues/97. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev