Drive detection stuff
rob at codeweavers.com
Fri Mar 4 09:49:47 CST 2005
Mike Hearn wrote:
>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"
This is a bug in either the shell folder code or the file dialog code
and should be fixed anyway.
>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
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 changed
> so we can update the UI, flush any caches etc?
I think either RegisterDeviceNotification or listening to the
WM_DEVICECHANGE message provide this service.
More information about the wine-devel