samba - Aug 2002 - AW: AW: Unable to open configuration file "/etc/smb.conf" (or whe reve r i specify)

> -----Urspr?ngliche Nachricht-----
> Von: nero one [mailto:nero_oner@yahoo.com]
> Gesendet: Dienstag, 13. August 2002 19:33
> An: Uli Luckas
> Cc: samba@lists.samba.org
> Betreff: Re: AW: Unable to open configuration file
"/etc/smb.conf" (or
> whereve r i specify)
> 
> 
> Hi Uli, 
> 
>    I'm not really sure what i'm looking for here, but here's 
> the result of the cat w/strace.
Well just to make sure, there is nothing wrong with the file.
> Seems its still return with result == 0?
> open("smb.conf", O_RDONLY|O_LARGEFILE)  = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1243, ...}) = 0
> brk(0x804e000)                          = 0x804e000
> read(3, "[global]\n\n   workgroup = WORKGRP"..., 512) = 512
And it looks like the file is ok.
Here we have the same sequence of system calls as in testparam. Only does
the read return 512 bytes, the full buffer size.
I am running out of ideas. Why does this read succeede while testparams read
returns 0 bytes?
Oh, I see a difference. From your testparam strace:

open("/etc/samba/smb.conf", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1243, ...}) = 0
read(3, "", 0)                          = 0
           ^^^
I thought read was called for 1243 bytes but it is called for 0 bytes. This
explains quite a bit :-)
It looks like the stat64 struct is not interpreted right.
Looking through the source again I find include/includes.h:
#ifdef BROKEN_REDHAT_7_STATFS_WORKAROUND
#undef _I386_STATFS_H
#undef BROKEN_REDHAT_7_STATFS_WORKAROUND
#endif

I read REDHAT_7 here. Did you reconfigure the sources from another machine?
Did you remove config.cache before configure?
What does the line:
samba_cv_BROKEN_REDHAT_7_SYSTEM_HEADERS=${samba_cv_BROKEN_REDHAT_7_SYSTEM_HE
ADERS=yes}
read in config.cache?
If you used an old config.cache remove it, if you had no old config.cache or
removed it already change the above line from yes to no or vice versa, rerun
configure and rebuild. Just a desperate guess, but this might be the
problem.

Uli