It calls UMD::isSupported() which calls getxattr. Trouble is that's a sync operation that may take any amount of time. That's particularly problematic when the path is on a mounted remote file system as we don't know how long that'll take but it can be a notable amount of time from protocol overhead alone. Do we even need FileFetchJob for remote FS? e.g. also Bug #42As in: would it be a good idea to run it on them to begin with?3487 seems less troublesome for local FS #0 0x00007f9f6e722e2e in getxattr () at ../sysdeps/unix/syscall-template.S:78 #1 0x00007f9f7037e578 in KFileMetaData::UserMetaData::isSupported() const () from /usr/lib/x86_64-linux-gnu/libKF5FileMetaData.so.3 #2 0x00007f9f708a1f7d in Baloo::FileFetchJob::doStart (this=0x2562ce0) at /home/me/src/baloo-widgets/src/filefetchjob.cpp:75 #3 0x00007f9f70894b61 in Baloo::FileFetchJob::qt_static_metacall (_o=0x2562ce0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x24947a8) at KF5BalooWidgets_autogen/EWIEGA46WW/moc_filefetchjob.cpp:72 #4 0x00007f9f6ee172a9 in QObject::event (this=0x2562ce0, e=0x2494760) at kernel/qobject.cpp:1339 #5 0x00007f9f6f9a7cc3 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
Created attachment 148694 [details] backtrace while gwenview is hung in getxattr() call I am experiencing this in Gwenview while paging through a directory of images mounted by mount.cifs. As I flip from one photo to the next, it doesn't take long before the UI locks up for about 35 seconds before finally responding again. Both strace and gdb indicate that the hang is in a call to getxattr("path.jpg", "user.baloo.rating", NULL, 0) Curiously, getxattr() doesn't noticeably hang in a test program that calls it in a loop with the same arguments, files, and mount point. I wonder what Baloo or Gwenview might be doing to trigger the 35 second delay. Gwenview Version: 20.12.3 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.16.0-0.bpo.4-amd64