Hi Nayana, it's awesome that you want to make this happen.
The problem is actually more complex than this:
* [in some cases] c-ares is the only "good" resolved for libcurl, and
* [when I last checked] c-ares reads /etc/resolv.conf only once
Thus, for a device that moves from network to network (e.g. wifi), has
a long-running process, needs domain name resolution timeouts (e.g.
wifi) and some other requirements (multithreaded IIRC, because libc
resolver uses a signal for timeout), this really is a problem.
It may seem that this circumstances are peculiar, but, actually many
IoT devices fall into this category.
Back in the day, I've tried to make a patch, but didn't have
time/stamina and couldn't put enough effort for it to be accepted.
https://gist.github.com/dimaqq/397682b68cdc0992a5d314c53e8ecf86 has the code.
The task is somewhat more complex than you stated, because resolv.conf
may contain several bits of configuration, and sometimes partial
update could break things (IIRC to resolve a LAN host, both `domain`
and `nameserver` are needed).
Cheers,
d.
On Thu, 15 Aug 2019 at 21:36, Nayanā Topolsky <nayana.topolsky_at_zoho.com> wrote:
>
> Hi,
>
> so I used just stat as the conf file is small, no need for 64bit version.
> However I was not sure if I should ifdef the stat structure usages as well?
>
> So the pull request is there, the only systems that use /etc/resolv.conf are Linux and OSX, which both passed via CI tests.
> I guess there are no win32 automated tests?
>
> Dňa 9. 8. 2019 o 9:02 Daniel Stenberg napísal(a):
>
> On Thu, 8 Aug 2019, Nayanā Topolsky wrote:
>
> I used stat64 function to check mtime and ctime and also size and ino values in very similar way as it is done in libc.
>
>
> stat(), or variations of it, should be fairly portable over many systems. (In the curl project we do stat on basically *all* platforms with just this little setup magic: https://github.com/curl/curl/blob/master/lib/curl_setup.h#L361-L396)
>
> The particular file name(s) you check which that call could also be system specific but should be possible to be made to work on a fair amount of systems.
>
> I can send a patch (or pull request) with hope that somebody else will continue the work on it. Or maybe it would be mergable even in this way.
>
>
> We will prefer a pull-request so that we get it somewhat verified before we consider merging and handling updates and reviews are also stream-lined that way.
>
> We can't guarantee that "somebody else" will magically continue working on it if you just drop it there though, I suppose it depends on how much work that remains...
>
> Thanks!
>
Received on 2019-08-26