DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)
andi at rhlx01.fht-esslingen.de
Wed Aug 28 13:41:25 CDT 2002
On Wed, Aug 28, 2002 at 06:35:08PM +0200, Martin Wilck wrote:
> I wrote on 2002-06-27:
> > > $ make test
> > > /home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so'
> > > make: *** [tests/alloc.ok] Fehler 1
> > Am I the only one with this problem? Or is it so trivial that I should
> > have figured it out?
> I have finally figured this out. It has to do with some (intentional?)
> DOSFS_FindUnixName() weirdness.
> My wine sources are in a directory /home/martin/Software/Wine/CVS/wine.
> /home/martin is my Windows drive Y:
> Now in /home/martin/Software, I have subdirectories "Wine" and "wine".
> DOSFS_FindUnixName() uses "wine" because
> a) DOSFS_ReadDir returns it first,
> b) The DOS short names match (the Unix names obviously don't).
> Since "wine" is the wrong path, the search fails shortly after.
> This happens even if I set the Filesystem type of drive Y: to "unix".
> I guess this is the right thing to do on Windows-style file systems,
> but should it be this way on a "unix" file system, too?
> The patch below does what I'd consider "sane" behaviour on Unix.
> Alternatively, on a "unix" filesystem, one could search the whole
> directory for exact matches, and try short names only if that fails.
Well, if your patch makes sure that on a "unix" mapping (as opposed to
"win95" !) we only lookup the *exact* case sensitive name instead of
iterating through all sorts of case cases (heh ! :), then I guess
your patch is right.
I guess nobody really cared about having correct behaviour of the "unix"
(since everybody should use "win95" for normal use anyway)
The Declaration of Software Freedom:
More information about the wine-devel