$ 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
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
--- Martin Wilck [email protected] 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
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)
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)
Martin Wilck [email protected] 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.
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; }
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+