Mail Archives: cygwin/2004/10/14/02:24:56
Hello Brian,
What we had was *not* a cygwin problem after all...
Brian Dessent wrote:
>Carlo Florendo wrote:
>
>
>
>>Anyway, I got this error:
>>
>>getservbyname() returned NULL: win32 error 11004
>>
>>
>
>Googling shows that this is consistent with trying to run a
>program/server that tries to look up its port in the services file when
>no such matching line exists.
>
>
>
>>I also read the message regarding the \r\n and \n line endings (still
>>not in my mailbox) and Corinna's reply. I've checked the services file
>>and confirmed that the line endings are \r\n (with the simple test of
>>^M showing up when invoking `vim -b'. Notepad also views the file
>>correctly, thus it's really \r\n.).
>>
>>I'm confident we're getting close!
>>
>>
>
>Closer yes,
>
Yes. In fact, ftp is working perfectly well now. Thank you very
much. More below...
>but I'm afraid I don't have much else coming to mind.
>Everything indicates that it's not finding what it's looking for in the
>services file.
>
Correct. That is because the services file wasn't present in the first
place. Let me explain...
Since the `services' file was involved, I thought of having a way to
monitor which files the ftp client accesses to make sure that it really
accesses the `services' file. I then remembered that I had this copy
of sysinternal's (www.sysinternals.com) filemonitor program filemon.exe
which displays file access on a system in real time. Thus, I simply
fired up filemon.exe, then fired up ftp, and poof, got the answer right
smack in my face.
ftp was trying to access c:\winnt\nsdb\services. I then checked my
system and c:\winnt\nsdb\ really existed but c:\winnt\nsdb\services did
not. Then, I wondered why it was looking at that directory and not
c:\winnt\system32\drivers\etc. I had no way of finding out where the
system got c:\winnt\nsdb but I first assumed that it got that location
from the registry. I fired up regedit and looked for all instances of
`nsdb'. Interestingly, I got this registry key/value:
\HKLM\SYSTEM\ControlSet001\Services\Tcpip\Parameters\DataBasePath =
%SystemRoot%\nsdb
I changed the registry entry value to
%SystemRoot%\system32\drivers\etc
then fired up ftp. Whew! It worked perfectly.
I searched on the cause of a modification of this registry entry and it
was a virus (which has long been removed from the system).
>One thing is clear though, this is not a Cygwin problem. The mingw
>example shows a minimal testcase that involves no Cygwin code at all,
>just direct calls to the Winsock functions. I'm willing to bet if you
>found a regular windows application that tried to look up a port using
>getservbyname() it would fail in the same way.
>
Correct again. In fact, I made a simple program in VC++ that used
getservbyname() and it failed exactly the same way as
your *.c codes.
> This is a relatively
>rare/antiquated thing to do as most apps either have the port
>configurable via a URL or a config file, or they just hard-code it.
>
>If you want a quick and dirty solution, comment out the call to
>getservbyname in the ftp source code and modify it to assume port 21.
>But that's admitting defeat, really.
>
>
>
We won't, we didn't and we won. Thanks Brian and to everyone for the
valuable comments which led us to lay this problem to rest.
On a curious note, why do the inetutils apps like ftp, telnet, etc.
still use getservbyname() and the other getserv functions when, as you
said,
these apps could just have the port and protocol hardcoded or specified
in a config file?
In any case, this is what I like with cygwin the cygwin mailing list.
They're the best! Cygwin...It Rocks!
Best Regards,
Carlo
--
Carlo Florendo
Astra Philippines Inc.
www.astra.ph
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -