Drive detection stuff
mike at navi.cx
Fri Mar 4 03:54:09 CST 2005
So, there are 4 obvious problems with our current drive management code:
1) We add links to the floppy drive. We should blacklist it, as it causes
a big delay in the file open dialogs as we poll the drive which sits
there spinning its motors naval-gazing. How many people still use
floppy disks in 2005 anyway? I'm hoping the answer is "virtually none"
2) We don't add any device symlinks. Some programs need these
eg d:: -> /dev/cdrom
3) The artwork in the file pickers sucks ass. Sorry, it does. It's ugly as
sin and for some reason the Desktop icon is an arrow, not a desk.
This doesn't matter when you only have C: and Z: drives. It does matter
when you have 2 CD drives, 2 Windows drives, a floppy and a few other
Fixing this is theoretically easy but for some reason it never gets
done. If any of you non-coders are reading this and want to contribute
then this would be a good way to start. Good artwork already exists,
it's just a case of finding it, converting it to the right format and
getting the new bitmaps into CVS.
4) We don't detect new drives as they are mounted into the system, eg if I
start a Windows program and then realize that my work is actually on a
USB key, if I plug that key in Nautilus and GTK+ (and probably KDE)
apps will detect it and see it, but we won't. Not even if I restart the
app! This is bad.
Fixing this is not, in theory, super hard. When HAL detects a new
hotplug device it modifies the fstab file and mounts. If we watch the
/etc/fstab file for changes and rerun drive detection therefore we can
make this all magically work. Problems are:
- Who triggers the resync? The wineserver is the obvious choice as
there is only 1 per wineprefix but we'd need to integrate FAM
support for that
- How do we broadcast to apps that the drive definitions changed
so we can update the UI, flush any caches etc?
More information about the wine-devel