Drive detection stuff

[Mike Hearn]

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

[Mike Hearn]

On Fri, 04 Mar 2005 09:54:09 +0000, Mike Hearn wrote:
> - 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.

[Alexandre Julliard]

Mike Hearn  writes:
> On Fri, 04 Mar 2005 09:54:09 +0000, Mike Hearn wrote:
> > - 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]

Mike Hearn  writes:
> - 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.

[Mike Hearn]

On Fri, 2005-03-04 at 11:18 +0100, Alexandre Julliard wrote:
> Mike Hearn  writes:
> > - 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

[Alexandre Julliard]

Mike Hearn  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).

[Mike Hearn]

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 :)

[Guido Draheim]

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

[Alexandre Julliard]

Guido Draheim  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.

[Holly Bostick]

Mike Hearn wrote:
> On Fri, 2005-03-04 at 11:18 +0100, Alexandre Julliard wrote:
> > Mike Hearn  writes:
> > > - 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

[Andreas Mohr]

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  writes:
> > > > - 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

[Holly Bostick]

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

[Francois Gouget]

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?

[Anssi Hannula]

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.

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard  writes:

Alexandre> Mike Hearn  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

[Andreas Mohr]

Hi,

On Fri, Mar 04, 2005 at 09:54:09AM +0000, Mike Hearn wrote:
> -
>
> 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

[Boaz Harrosh]

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.

[Andreas Mohr]

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

[Steven Edwards]

Hi Andres,

--- Andreas Mohr  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/

[Paul van Schayck]

On Fri, 04 Mar 2005 09:54:09 +0000, 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"

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

[Rob Shearman]

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 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

[Jacek Caban]

Mike Hearn wrote:
> - 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