Comment 136 for bug 539515

In response to Martin Pitt's comment #108:
I am one of the floppy owners ``bugged'' by bug #441835. I agree (but is only my humble opinion) that the patch that has been submitted to this bug is a solution only for the people in category 3) according to Francisco Cabanas' comment. I hope that the solution can be found elsewhere... but I need your help to demonstrate it :-)

The thing that mostly puzzles me is that, while udisks is trying to open the floppy drive, there is a very long sequence of poll() calls on other drives. This is what I understood from Sebastien Bacher's attachment #106. This seems strange to me, because polling of /dev/sr? should not depend on the slowness of the floppy drive.

I am attaching a very small Python script to this comment. It just tries to open /dev/fd0 and then prints its results. That is: it does the thing that Martin disabled with his latest patch to udisks.

Can someone please run this small script on a system without the floppy drive, but with the floppy drive icon, like helmut0 or Sebastien? The script should be run like this:

sudo python disk_tester.py

I guess it is not polite to ask people to run sudo-ed commands onto their systems, but you can actually _read_ from the source that the script will make no harm to your system.

If the above script takes a very long time to execute, then Martin's patch is probably the only way to cope with the non-existing floppy drives: even a open() call takes too long, and the problem must be fixed in the kernel or somewhere else.
But, OTOH, if _all_ systems take a very small time to run the script, then the problem may be in another part of udisks.

Thank you in advance!