After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 157820 - Unnecessary floppy disk drive access
Unnecessary floppy disk drive access
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.4.x
Other Windows
: Low minor
: Small fix
Assigned To: gtk-win32 maintainers
gtk-bugs
: 172977 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-11-10 03:16 UTC by Ben W.
Modified: 2005-04-07 20:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ben W. 2004-11-10 03:16:52 UTC
When using the lighting effects plugin, if I try to save or open a lighting
preset, the plugin attempts to read my floppy drive before it displays the
save/open dialog, (thereby creating a small delay).  There is no disk in the
drive and the lighting plugin is the only one that I know of with this behavior.
 The main image open/save dialogs are not affected.

I am running a (recent) clean install of windows XP.  My floppy disk drive shows
no other strange behavior and works fine.

This is a minor problem, but I thought I'd mention it in case the solution was
simple.
Comment 1 Michael Schumacher 2004-11-10 09:20:39 UTC
I think this is a problem of GTK+ - the same happens with Ethereal.
Comment 2 Hans Breuer 2004-12-06 00:15:22 UTC
Is the selection of the file dialog on the first entry: your floppy ?
If so it would be intersting how it got there. [I'm unable to test
this myself cause none of my computers has a floppy drive anymore]
Comment 3 Robert Ögren 2004-12-06 19:39:46 UTC
I can reproduce this even with testfilechooser. The floppy access occurs when
GetVolumeInformationW is called in gtk_file_system_win32_volume_get_display_name
for the floppy, when adding the volumes to the shortcuts list.

If the delay is undesirable I think the easiest solution is to simply skip
calling GetVolumeInformationW for floppy drives - how many people use floppies
these days, give them a label and desperately need to see the label in the file
chooser? As far as I can see the standard win32 file dialogs don't show the
floppy label either (WinXP).
Comment 4 Tor Lillqvist 2004-12-29 20:16:21 UTC
BTW, is it always true that drives A: and B:, if present, are floppies? Or can 
they be other kinds of drives on systems without any floppy drives present?
Comment 5 J. Ali Harlow 2004-12-29 20:29:45 UTC
I think you can always treat A and B as floppies although they may not be
physical floppies (eg., when booting from a CD-ROM).
Comment 6 Tor Lillqvist 2004-12-29 20:32:19 UTC
Testing reveals that B: (and presumably A:) can be a network drive, my machine 
has just one floppy, and connecting B: to a server share works fine. 

If GetDriveType() for A:\ or B:\ returns DRIVE_REMOVABLE, can one then be sure 
it is a floppy (and GetVolumeInformation should be avoided)? Can other drives 
than A: and B: be floppies? (Not likely these days, of course.) 
Comment 7 J. Ali Harlow 2004-12-29 20:41:12 UTC
Good catch. I hadn't considered the possibility of a user adding a share.

Standard floppy controllers can only address two floppies, but I don't know
about LS-120 drives. I think it's only possible to address one floppy controller
(ie., there's only one I/O address assigned), but I'd have to check at work to
be sure.
Comment 8 Tor Lillqvist 2004-12-31 01:46:26 UTC
Will be fixed together with bug #161797.
Comment 9 Tor Lillqvist 2005-01-02 23:27:49 UTC
GetVolumeInformation is now not called for drives A: or B: if they are 
removable:

2005-01-02  Tor Lillqvist  <tml@iki.fi>

	* gtk/gtkfilesystemwin32.c
        (gtk_file_system_win32_volume_get_display_name): Don't call
	GetVolumeInformation() on drives A: or B: if they are removable,
	as they might then be floppies, causing an unnecessary
	delay. (#157820)
Comment 10 Sven Neumann 2005-04-07 20:44:57 UTC
*** Bug 172977 has been marked as a duplicate of this bug. ***