Drive detection stuff
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 drives. 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? thanks -mike
On Fri, 04 Mar 2005 09:54:09 +0000, Mike Hearn wrote:
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"
An alternative solution would be to poll the drives in a non-blocking manner, though I'm not sure this would work for apps which do their own file dialogs like Office.
Mike Hearn <mike(a)navi.cx> writes:
On Fri, 04 Mar 2005 09:54:09 +0000, Mike Hearn wrote:
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"
An alternative solution would be to poll the drives in a non-blocking manner, though I'm not sure this would work for apps which do their own file dialogs like Office.
There really shouldn't be any case where we poll the drives. Currently we do it on startup to fill the registry with cdrom information but that should be fixed. -- Alexandre Julliard julliard(a)winehq.org
Mike Hearn <mike(a)navi.cx> writes:
2) We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom
That should never be needed on a standard setup. If you know of a case where it's required that should be considered a bug. -- Alexandre Julliard julliard(a)winehq.org
On Fri, 2005-03-04 at 11:18 +0100, Alexandre Julliard wrote:
Mike Hearn <mike(a)navi.cx> writes:
2) We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom
That should never be needed on a standard setup. If you know of a case where it's required that should be considered a bug.
I thought some programs used them to determine free disk space and control CD audio amongst other odd things. Half-Life does that to play its music. At least, I seem to recall adding the :: symlinks being the answer to quite a few tech support queries on #winehq, and I know I've needed to do it before. Is there anything apart from low level drive access where the device symlink is needed? thanks -mike
Mike Hearn <mike(a)navi.cx> writes:
At least, I seem to recall adding the :: symlinks being the answer to quite a few tech support queries on #winehq, and I know I've needed to do it before. Is there anything apart from low level drive access where the device symlink is needed?
It's not needed for low level drive access either, it's all automatically detected. The exception is with "exotic" setups like the ones using an automounter (though that could probably be fixed too, it just hasn't been done yet). -- Alexandre Julliard julliard(a)winehq.org
On Fri, 2005-03-04 at 11:30 +0100, Alexandre Julliard wrote:
It's not needed for low level drive access either, it's all automatically detected. The exception is with "exotic" setups like the ones using an automounter (though that could probably be fixed too, it just hasn't been done yet).
Ah, I see. OK, scratch that one from the list then :)
Mike Hearn wrote:
On Fri, 2005-03-04 at 11:30 +0100, Alexandre Julliard wrote:
It's not needed for low level drive access either, it's all automatically detected. The exception is with "exotic" setups like the ones using an automounter (though that could probably be fixed too, it just hasn't been done yet).
Ah, I see. OK, scratch that one from the list then :)
Thanks reminding the "exotic" setups. I did just stop updating to the latest wine at some point. Too many exotic changes in wine since then. :-)=) http://bugs.winehq.org/show_bug.cgi?id=1283 have fun, -- guido http://google.de/search?q=guidod
Guido Draheim <guidod-2003-(a)gmx.de> writes:
Thanks reminding the "exotic" setups. I did just stop updating to the latest wine at some point. Too many exotic changes in wine since then. :-)=) http://bugs.winehq.org/show_bug.cgi?id=1283
As it says in the bug, this should no longer be an issue with the new filesystem handling. You should be able to create a drive symlink to the drive mount point and things should work fine. If they don't please let us know what the problem is. -- Alexandre Julliard julliard(a)winehq.org
Mike Hearn wrote:
On Fri, 2005-03-04 at 11:18 +0100, Alexandre Julliard wrote:
Mike Hearn <mike(a)navi.cx> writes:
2) We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom That should never be needed on a standard setup. If you know of a case where it's required that should be considered a bug.
I thought some programs used them to determine free disk space
Speaking of free disk space detection.... I have had it happen with at least 2 different programs (I can document more fully, just not this second) that if I have a 20 GB partition ("games", 6GB free) mounted in my home directory (/home/holly/games, but /home itself has only a few hundred MB free), and try to install an app to Y:\games\app_name, I get a warning (or in one case a stop) that there is not enough drive space to install the app because there is not enough space on Y:\ (i.e., in /home), but there is, in reality, enough space in Y:\games (i.e., in the mounted partition). Whether the program will allow me to install seems to depend on whether it's old and thinks it knows everything, or not so old, and is willing to let me override what it thinks it sees in terms of drive space; if the program allows me to install anyway, the program naturally installs fine, since there is enough space. Now naturally, this could be solved by creating a direct symlink to /games in dosdevices, but that's an extra step I don't always feel like being bothered with (let's say I'm in a hurry), especially when the partition is mounted into /home, which is automatically symlinked in dosdevices anyway, so the drive is already accessible via a "short path" (y:\games); shortening the path to just a drive letter isn't necessarily worth the effort. Sorry to introduce a side issue, but if drive space detection is related to drive detection, I thought I'd mention this so that it doesn't get lost in any adjusted code. This may be thought to be an 'exotic' setup, but I am sure I'm not the only one with mounted data partitions (LVM, actually, but they wouldn't have to be) for easy access, partition size management, and simplified backup. Holly
Hi, On Fri, Mar 04, 2005 at 01:57:55PM +0100, Holly Bostick wrote:
Mike Hearn wrote:
On Fri, 2005-03-04 at 11:18 +0100, Alexandre Julliard wrote:
Mike Hearn <mike(a)navi.cx> writes:
2) We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom That should never be needed on a standard setup. If you know of a case where it's required that should be considered a bug.
I thought some programs used them to determine free disk space
Speaking of free disk space detection.... I have had it happen with at least 2 different programs (I can document more fully, just not this second) that if I have a 20 GB partition ("games", 6GB free) mounted in my home directory (/home/holly/games, but /home itself has only a few hundred MB free), and try to install an app to Y:\games\app_name, I get a warning (or in one case a stop) that there is not enough drive space to install the app because there is not enough space on Y:\ (i.e., in /home), but there is, in reality, enough space in Y:\games (i.e., in the mounted partition). Whether the program will allow me to install seems to depend on whether it's old and thinks it knows everything, or not so old, and is willing to let me override what it thinks it sees in terms of drive space; if the program allows me to install anyway, the program naturally installs fine, since there is enough space. Free space detection is strictly being based on the properties of the current "main" partition mapping, as it should be. There really isn't any way for Wine to account for a "mysteriously much bigger" "special" directory inside the current drive that Wine sees.
It really cannot be solved by anything else other than the end user, by creating a new drive mapping for the specially spacey sub directory. Again, drive mapping focuses on the space properties of the partition containing the root directory of the mapping, since this very drive letter is the only reference point of windows programs. It wouldn't even make sense to let Wine *manually* (i.e. very wasteful operation!) figure out the combined disk space of the sub directories beyond a drive mapping and advertise the combined space to Windows programs, since then you give a free space of 60GB for /home/holly, whereas the program will die a HORRIBLE death if it then boldly goes on with installing a 50GB game in /home/holly/install_dir... If you have further mount points below another drive, then the user DOES need to advertise this as another drive letter mapping to let Windows programs know about it properly without any opportunities for failure. Andreas Mohr
Andreas Mohr wrote:
Hi,
On Fri, Mar 04, 2005 at 01:57:55PM +0100, Holly Bostick wrote:
Speaking of free disk space detection.... I have had it happen with at least 2 different programs (I can document more fully, just not this second) that if I have a 20 GB partition ("games", 6GB free) mounted in my home directory (/home/holly/games, but /home itself has only a few hundred MB free), and try to install an app to Y:\games\app_name, I get a warning (or in one case a stop) that there is not enough drive space to install the app because there is not enough space on Y:\ (i.e., in /home), but there is, in reality, enough space in Y:\games (i.e., in the mounted partition).
It really cannot be solved by anything else other than the end user, by creating a new drive mapping for the specially spacey sub directory.
Again, drive mapping focuses on the space properties of the partition containing the root directory of the mapping, since this very drive letter is the only reference point of windows programs. It wouldn't even make sense to let Wine *manually* (i.e. very wasteful operation!) figure out the combined disk space of the sub directories beyond a drive mapping and advertise the combined space to Windows programs, since then you give a free space of 60GB for /home/holly, whereas the program will die a HORRIBLE death if it then boldly goes on with installing a 50GB game in /home/holly/install_dir...
If you have further mount points below another drive, then the user DOES need to advertise this as another drive letter mapping to let Windows programs know about it properly without any opportunities for failure.
Andreas Mohr
Fair enough (if unfortunate). I guess this is one of the Linux advantages that cannot be munged so that Windows programs can make use of it :-( . Oh, well, another addition to my "To-do" list, then; make a note of this for documentation patch purposes. I'm sure that I'm not the only one who might get caught by this unexpectedly. Thanks for explaining. Holly
On Fri, 4 Mar 2005, Andreas Mohr wrote: [...]
Free space detection is strictly being based on the properties of the current "main" partition mapping, as it should be. There really isn't any way for Wine to account for a "mysteriously much bigger" "special" directory inside the current drive that Wine sees.
Doesn't Windows 2000 and greater let you mount network drives in arbitrary places in the filesystem (another Microsoft 'invention' I guees). Note that this is from some fuzzy memories of reading stuff about it, not that I ever used this functionality myself. If this does indeed work, then there may be more free disk space in "c:\Program Files" than in "c:\" and it would be interesting to see how Windows deals with this. So can anyone confirm whether I remember right? If yes, how does one do this kind of mounting and how does Windows deal with them when reporting the free disk space? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
Francois Gouget wrote:
On Fri, 4 Mar 2005, Andreas Mohr wrote: [...]
Free space detection is strictly being based on the properties of the current "main" partition mapping, as it should be. There really isn't any way for Wine to account for a "mysteriously much bigger" "special" directory inside the current drive that Wine sees.
Doesn't Windows 2000 and greater let you mount network drives in arbitrary places in the filesystem (another Microsoft 'invention' I guees).
Note that this is from some fuzzy memories of reading stuff about it, not that I ever used this functionality myself. If this does indeed work, then there may be more free disk space in "c:\Program Files" than in "c:\" and it would be interesting to see how Windows deals with this.
So can anyone confirm whether I remember right? If yes, how does one do this kind of mounting and how does Windows deal with them when reporting the free disk space?
Yep, that's true. You can mount normal drives as folders, too. I haven't tested it, but it indeed would be interesting to see how Windows does the free space calculations etc. -- Anssi Hannula
"Alexandre" == Alexandre Julliard <julliard(a)winehq.org> writes:
Alexandre> Mike Hearn <mike(a)navi.cx> writes: >> 2) We don't add any device symlinks. Some programs need these eg d:: >> -> /dev/cdrom Alexandre> That should never be needed on a standard setup. If you know Alexandre> of a case where it's required that should be considered a Alexandre> bug. Some audio program look for available drive by drive letter and then access the device by X::, sending ioctl to the device. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Hi, On Fri, Mar 04, 2005 at 09:54:09AM +0000, Mike Hearn wrote:
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? See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/k... and maybe http://support.microsoft.com/default.aspx?scid=kb;en-us;867819 for how Windows does drive letter assignment (drive notification)
Are you sure the apps get notified, too? ISTR XP doesn't automatically update the Explorer view after you have plugged in a USB stick, or maybe I'm wrong? Andreas Mohr
Andreas Mohr wrote:
Are you sure the apps get notified, too? ISTR XP doesn't automatically update the Explorer view after you have plugged in a USB stick, or maybe I'm wrong?
Yes it does. and any program can. There is an API to watch for File System changes. From files (for editors), to folders and drives. The standard Shell control (Used in file dialogs and Explorer) uses this API by default. Also apps that do their own Dialogs like office.
Hi, On Fri, Mar 04, 2005 at 01:08:27PM +0200, Boaz Harrosh wrote:
Andreas Mohr wrote:
Are you sure the apps get notified, too? ISTR XP doesn't automatically update the Explorer view after you have plugged in a USB stick, or maybe I'm wrong?
Yes it does. and any program can. There is an API to watch for File System changes. From files (for editors), to folders and drives. The standard Shell control (Used in file dialogs and Explorer) uses this API by default. Also apps that do their own Dialogs like office.
Ah, so this means that the directory change notification mechanism applies to volume notification as well? Or is it still a somewhat separate API? Nevermind, at least you just told us that this API exists, so we should try to get the hal/hotplug/fam stuff integratedf towards this API. Andreas Mohr
Hi Andres, --- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/k...
and maybe http://support.microsoft.com/default.aspx?scid=kb;en-us;867819 for how Windows does drive letter assignment (drive notification)
Are you sure the apps get notified, too? ISTR XP doesn't automatically update the Explorer view after you have plugged in a USB stick, or maybe I'm wrong?
I think the umpnpmgr.exe in windows takes care of all of this for the applications and explorer using the APIs you listed. I don't know how we would really fit in the Windows design here. http://msdn.microsoft.com/library/en-us/kmarch/pnpcomp.wmf Thanks Steven __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/
On Fri, 04 Mar 2005 09:54:09 +0000, Mike Hearn <mike(a)navi.cx> 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"
Me. And I've seen at least two times people use wine for those bios flash floppy creation tools. It's not easy to know if an entry in fstab is a floppy device. As they are always set to 'auto' as fstype. So we have to look at the mount point and/or device node name to blacklist it. Currently we're actually looking at the device node name to see if it's a floppy device. Paul
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. Rob
Mike Hearn wrote:
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 drives.
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.
I know two (maybe there are more) projects that have done really nice artwork: xpde (www.xpde.com) and kde xp style (http://kdelook.org/content/show.php?content=1499). The main problem is that both have GPL licence, but we could ask authors to let us use them in Wine. Their icons are really cool and I belive Wine would look much better with them.
thanks -mike
Thanks, Jacek
participants (13)
-
Alexandre Julliard -
Andreas Mohr -
Anssi Hannula -
Boaz Harrosh -
Francois Gouget -
Guido Draheim -
Holly Bostick -
Jacek Caban -
Mike Hearn -
Paul van Schayck -
Rob Shearman -
Steven Edwards -
Uwe Bonnes