Version: 0.12.4a (using KDE KDE 3.4.2) Installed from: Debian testing/unstable Packages OS: Linux Nikita V. Youshchenko <yoush at cs.msu.su> reported the following problem on the Debian bug tracking system (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274998): We are running a network where users work on X terminals connected to a Debian Linux server. Server has 2 writer devices; Linux seems to support simultaneous writing on both. While k3b started from one user was writing, k3b started from another user hanged at 'Scanning for devices' stage for a long time (several minutes). Although it unblocked before writing was complete, several minutes of freeze does not seem to be dummy-user-friendly :). Most likely, this is caused by the fact that k3b uses some device ioclt while scanning, which in-kernel implementation tries to gain an exclusive lock to the device. Which in turn blocks entire process until another in-kernel usage unblocks the device. Proper fix will probably need some cooperation between k3b and kernel people, to make it possible to read device characteristics (or whatever k3b needs while "scanning devices") without blocking. To make situation a bit better involving k3b only, k3b probably should split scanning ioctls into a separate thread (to avoid GUI freeze) and inform user what's going on (e.g. "looks like device is locked by another user, waiting for lock to be released"). This will not solve the problem - user will still be unable to start writing on other writer - but anyway it's better than hanging.
that's why k3b is a unique app. sorry, but I have no time for low-prio problems like this at the moment.
Could you please check if this bug still occurs with the recent version of k3b (0.12.17 or 1.0pre2)?
Changed to a wish.
*** Bug 114919 has been marked as a duplicate of this bug. ***
*** Bug 146843 has been marked as a duplicate of this bug. ***