(HELP) cannot run tests anymore

[Martin Wilck]

$ make test
/home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so'
make: *** [tests/alloc.ok] Fehler 1

What am I doing wrong? I have tried this and that, but I don't seem to be able to
run the tests. This happens for any tests I try.
It seems that wine isn't looking for "tests/kernel32_test.exe.so" below the current directory.

Martin

[Martin Wilck]

Am Mit, 2002-06-26 um 12.53 schrieb Martin Wilck:
> $ 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?

The problem seems to have materialized some time between Wine-20020509
and Wine-20020605.

Martin

[Andriy Palamarchuk]

--- Martin Wilck 
wrote:
> Am Mit, 2002-06-26 um 12.53 schrieb Martin Wilck:
> > $ 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 similiar bug different problem:

../../programs/winetest/runtest -q -P wine -M
kernel32.dll -T ../.. tests/atom.pl && touch
tests/atom.ok
Could not exec winetest.exe

I found out this problem only recently.

Andriy

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

[Martin Wilck]

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.

Martin

Index: dos_fs.c
===================================================================
RCS file: /home/wine/wine/files/dos_fs.c,v
retrieving revision 1.117
diff -u -r1.117 dos_fs.c
--- dos_fs.c	27 Aug 2002 01:13:59 -0000	1.117
+++ dos_fs.c	28 Aug 2002 16:27:47 -0000
@@ -760,7 +760,7 @@
                 if (!strncmpiW( long_name, name, len )) break;
             }
         }
-        if (dos_name[0])
+        if (dos_name[0] && ignore_case)
         {
             /* Check against hashed DOS name */
             if (!short_name)

DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

[Andreas Mohr]

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"
mapping mode.
(since everybody should use "win95" for normal use anyway)

DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

[Alexandre Julliard]

Martin Wilck  writes:
> 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'd say that DOSFS_ToDosFCBFormat should fail when the file contains
upper-case chars on a case-sensitive file system. This will probably
make it impossible to access some files in certain cases though. I'm
afraid it's not possible to support case-sensitive file systems 100%
right given that Windows apps don't preserve case correctly.

DOSFS_FindUnixName and "unix" filesystem (was: Re: (HELP) ...)

[Martin Wilck]

Am Don, 2002-08-29 um 03.25 schrieb Alexandre Julliard:
> I'd say that DOSFS_ToDosFCBFormat should fail when the file contains
> upper-case chars on a case-sensitive file system. This will probably
> make it impossible to access some files in certain cases though. I'm
> afraid it's not possible to support case-sensitive file systems 100%
> right given that Windows apps don't preserve case correctly.

I propose another patch with is is IMO the least intrusive:

- changes nothing for non-"unix" filesystems
- for "unix", searches the whole directory for exact matches first,
  then again for DOS matches; i.e. DOS matches will be used, but only
  if there are no exact ones.

Sorry the patch is difficult to read - you'll see the point if you
compare the patched an non-patched versions visually.

In any case this is relatively minor and we can live without. If we
don't patch, we need to be prepared that other people stumble into the
problem I had, though. I am still feeling dumb - my wine development was
practically stuck for 2 months because of that "wine" file.

Martin

Index: dos_fs.c
===================================================================
RCS file: /home/wine/wine/files/dos_fs.c,v
retrieving revision 1.117
diff -u -r1.117 dos_fs.c
--- dos_fs.c	27 Aug 2002 01:13:59 -0000	1.117
+++ dos_fs.c	29 Aug 2002 08:34:51 -0000
@@ -746,31 +746,53 @@
         return FALSE;
     }

-    while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
+    if (ignore_case)
     {
-        /* Check against Unix name */
-        if (len == strlenW(long_name))
+        while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
         {
-            if (!ignore_case)
+            /* Check against Unix name */
+            if (len == strlenW(long_name) && !strncmpiW( long_name, name, len ))
+                goto found;
+
+            if (dos_name[0])
             {
-                if (!strncmpW( long_name, name, len )) break;
-            }
-            else
-            {
-                if (!strncmpiW( long_name, name, len )) break;
+                /* Check against hashed DOS name */
+                if (!short_name)
+                {
+                    DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case );
+                    short_name = tmp_buf;
+                }
+                if (!strcmpW( dos_name, short_name )) goto found;
             }
         }
-        if (dos_name[0])
+    }
+    else /* ignore_case ("unix" file system): try to find exact match first */
+    {
+        while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
+            if (len == strlenW(long_name) && !strncmpW( long_name, name, len ))
+                goto found;
+
+        DOSFS_CloseDir( dir );
+        dir = DOSFS_OpenDir( DRIVE_GetCodepage(path->drive), path->long_name );
+
+        while ((ret = DOSFS_ReadDir( dir, &long_name, &short_name )))
         {
-            /* Check against hashed DOS name */
-            if (!short_name)
+            if (dos_name[0])
             {
-                DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case );
-                short_name = tmp_buf;
+                /* Check against hashed DOS name */
+                if (!short_name)
+                {
+                    DOSFS_Hash( long_name, tmp_buf, TRUE, ignore_case );
+                    short_name = tmp_buf;
+                }
+                if (!strcmpW( dos_name, short_name )) goto found;
             }
-            if (!strcmpW( dos_name, short_name )) break;
         }
     }
+
+found:
+    DOSFS_CloseDir( dir );
+
     if (ret)
     {
         if (long_buf) WideCharToMultiByte(DRIVE_GetCodepage(path->drive), 0,
@@ -787,7 +809,6 @@
     }
     else
         WARN("%s not found in '%s'\n", debugstr_w(name), path->long_name);
-    DOSFS_CloseDir( dir );
     return ret;
 }

[Eric Pouech]

Martin Wilck a écrit :
> $ make test
> /home/martin/Software/Wine/TMP/wine/miscemu/wine: cannot find 'tests/kernel32_test.exe.so'
> make: *** [tests/alloc.ok] Fehler 1
>
> What am I doing wrong? I have tried this and that, but I don't seem to be able to
> run the tests. This happens for any tests I try.
> It seems that wine isn't looking for "tests/kernel32_test.exe.so" below the current directory.

works fine here (except for some other errors, see wine-patches)
A+