readdir broken when called from wine

[Lionel Elie Mamane]

Hi,

After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled
from tarballs), suddenly it didn't find my "C:\Windows" any
more. Worked before, same 'puter, config files, etc (TM). Tried with
CVS version. Nope. I recruited Andreas Mohr on #WineHQ for help, we
ruled out the obvious (yes, the directory exists, here is my config
file, no, I don't confuse root and non-root, ...), and got down to add
traces and dug in the code.

So, for some reason, the readdir calls from
files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL),
but the directory entry name returned (dirent->d_name) is always the
empty string (*(dirent->d_name)=='\0')!

So I checked if readdir worked generally on my system, it does, this
program does the expected thing:
int main(void)
    {//Tst code
      DIR *mydir;
      struct dirent *entr;
      mydir = opendir("/");
      while ((entr = readdir(mydir)))
    {
      TRACE("Dir_entry: %s\n", entr->d_name);
    }
      closedir(mydir);
    }

I even went the extra mile and compiled it with exactly the same
options (minus the various -I's) as dos_fc.c gets in wine, it works.

Then, I added that code snippet (without the "int main(void)",
obviously) to wine's main(). Worked. So I went down the stack of
called functions, putting that same snippet in each function to see
when it breaks:

It works "up to" (or down to?) loader/main.c:MAIN_MainInit(). That
function calls files/directory.c:DIR_Init(), and there, it doesn't
work (ie name is always empty string) in DIR_Init(). After DIR_Init()
returns, it still works in MAIN_MainInit().

I tried to find a difference between these files, but they get
compiled with the same compile options, combined by "ld -r" along with
other .o's in files/files.o, resp. loader/loader.o, and the two latter
go in libntdll.so.

What could be the difference that makes readdir "break"?

I've put the test code snippet just before the call to DIR_Init in
MAIN_MainInit, and just after variable declaration in DIR_Init, so
it's not a function that DIR_Init calls that "breaks havoc".

Well... We're lost there. No idea. Anyone of you?

Anyway, here's some info on my system, just giving random info, I
don't really know which one will be useful:

Pentium III 500 / 440BX motherboard
SuSE 6.4 distrib "base" with several self-compiled "add-ons",
"upgrades", and some newer SuSE RPM's installed (from 7.0, 7.1 or
7.2). Along the latter (newer RPM than SuSE 6.4), the glibc...
glibc-2.2-9
Linux 2.2.20 (Was using .19 when problem started)
Soundblaster AWE32
3Com NIC (3C905B)
Adaptec SCSI controller (AHA-3950U2)
gcc 2.95.2
GNU ld 2.9.5
binutils-2.9.5.0.24-30

Err... What more??? Any additional info useful? Just ask. (except r00t
password, "of course" ;-> )

Thank you for your time,

[Marcus Meissner]

On Sun, Nov 18, 2001 at 08:17:24PM +0100, Lionel Elie Mamane wrote:
> Hi,
>
> After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled
> from tarballs), suddenly it didn't find my "C:\Windows" any
> more. Worked before, same 'puter, config files, etc (TM). Tried with
> CVS version. Nope. I recruited Andreas Mohr on #WineHQ for help, we
> ruled out the obvious (yes, the directory exists, here is my config
> file, no, I don't confuse root and non-root, ...), and got down to add
> traces and dug in the code.
>
> So, for some reason, the readdir calls from
> files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL),
> but the directory entry name returned (dirent->d_name) is always the
> empty string (*(dirent->d_name)=='\0')!

Did you upgrade glibc?

Ciao, Marcus

[Lionel Elie Mamane]

On Sun, Nov 18, 2001 at 10:26:20PM +0100, Marcus Meissner wrote:
> > So, for some reason, the readdir calls from
> > files/dos_fs.c:DOSFS_ReadDir() report success (ie return non-NULL),
> > but the directory entry name returned (dirent->d_name) is always the
> > empty string (*(dirent->d_name)=='\0')!
> Did you upgrade glibc?

Well, yes, but not between the compilation and the running. Did a
fresh recompile of 20010418 with the new glibc (I honestly don't
remember if the 20010418 release was compiled with the "old" one or
the "new"), works. 20011004 does not. With the same glibc.

Horrible doubt... Have I upgraded the _header_ files too? rpm would
have loudly complained if I hadn't. It would have. Or am I too used to
Debian quality? I didn't upgrade the headers. Doing so. Recompiling.
OK, problem solved. Sorry.

Now, if someone could explain to me how the symptoms...

[Ove Kaaven]

On Sun, 18 Nov 2001, Lionel Elie Mamane wrote:
> It works "up to" (or down to?) loader/main.c:MAIN_MainInit(). That
> function calls files/directory.c:DIR_Init(), and there, it doesn't
> work (ie name is always empty string) in DIR_Init(). After DIR_Init()
> returns, it still works in MAIN_MainInit().
>
> I tried to find a difference between these files, but they get
> compiled with the same compile options, combined by "ld -r" along with
> other .o's in files/files.o, resp. loader/loader.o, and the two latter
> go in libntdll.so.
>
> What could be the difference that makes readdir "break"?

One file includes config.h before including system (libc) headers, the
other does not. config.h may contain definitions that affect the
structures that get included. For example, _FILE_OFFSET_BITS 64, which
requests 64-bit filesystem stuff.