Mike Hearn wrote:
So, there are 4 obvious problems with our current drive management code:
- 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"
This is a bug in either the shell folder code or the file dialog code and should be fixed anyway.
- 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
Ugh. Rescanning /etc/fstab seems like an ugly way to do this. It would probably be better to have this all in another process that listens to HAL events properly and sends out the appropriate notifications and does DefineDosDevice as needed.
- How do we broadcast to apps that the drive definitions changedso we can update the UI, flush any caches etc?
I think either RegisterDeviceNotification or listening to the WM_DEVICECHANGE message provide this service.
Rob