[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    re: Detecting Wine
From:       "Dan Kegel" <dank () kegel ! com>
Date:       2008-09-30 12:34:28
Message-ID: a71bd89a0809300534u3f94b9cm5e6e8f9ce2de43ae () mail ! gmail ! com
[Download RAW message or body]

Mark W. wrote:
>As part of the installation process, under Windows our
>program does a full-disk search of all local hard drives,
>but ignoring network drives and removable media.
>Under Wine, this doesn't work too well, as there's not
>a one-to-one mapping between disks and drive letters,
>and there's usually at least one way to access the entire *nix
>filesystem. If someone's got a few network drives mounted,
>the installer could spend hours searching them.

We have a similar issue in Picasa.   There, we try to
default to just searching the user's home directory
when running on Wine, and I think we blacklist
known do-not-search directories like /proc.
We have gone back and forth about whether to
follow symlinks; there are often symlinks to
network filesystems inside people's home directories.

The right thing to do is probably something like:

a) get the set of initial seeds by using the output
of the 'mount' command and ignoring anything with
a type field that is not a known local filesystem type
(e.g. ext2, ext3, ufs, reiserfs, xfs); you'll need to expand
this whitelist as customers complain about their pet filesystems
(And you'll need to ignore any that can't be mapped
to Wine paths, but people usually map Z: to /.)
(You could use /proc/mounts under Linux, but
better to use the standardized 'mount' command
or maybe /etc/mtab, otherwise your code will break
on MacOSX or Solaris.)

b) when recursing, and you find a reparse point aka symlink,
check the filesystem type of the symlink destination
before following it.  You might need to get bug
http://bugs.winehq.org/show_bug.cgi?id=12401 fixed
before this works the windows way, but you could
probably do something wine-specific now by
converting each directory path you encounter
into a unix path, then using a unix api to check
whether it's a symbolic link.  Bleah.  Best way
to do that is to patch wine, and then you're part
way to fixing bug 12401 :-)

c) beware: Wine's implementation of FindFirstChange/FindNextChange
does not really work if you ask it to monitor two different
names for the same directory.  See
http://bugs.winehq.org/show_bug.cgi?id=7216
- Dan


[prev in list] [next in list] [prev in thread] [next in thread]