Micah, Thanks for your explanations. I will take a look at that. I will prepare a brand-new patch to encompass those features. I guess next time I should first get sure before start coding, being cheated is sad :(
Thanks, Julien. On Feb 10, 2008 4:32 AM, Micah Cowan <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Julien B. wrote: > > Currently, when calling the initialize() function into init.c, before > > to check if the user and system wgetrc point to the same location, no > > canonicalization is done. > > This results in leaving wget unable to follow links, or to understand > > relative paths once user and system wgetrc are found. > > However, a warning should be raised to the user when both user and > > system wget point to the same location. > > My patch considers to improve this, by the use of the realpath(3) function. > > If you have ideas on how to better implement this, tell me, I would be > > glad to work on it to match all requirements. > > Thanks for the patch. :) > > But, I'm concerned that (1) realpath() may not be portable across > platforms, (2) the use of NULL for the second argument in realpath() is > decidedly unportable, (3) even when the two paths may differ, they > _still_ may point to the same file (if they are "hard" links to the same > file). It seems to me a better check would involve stat() or similar, > and comparing the st_dev and st_ino fields to determine whether they're > ultimately the same file. Best would be opening the two files ahead of > time, and using fstat(), to avoid a race condition. > > I know, I know, this fix is suggested by an actual comment in the source > code (which I should fix), and I'm still not accepting it. You've been > cheated. :\ > > I would accept a patch that uses the stat() (or, especially fstat()) > solution. > > There are also a couple related fixes that are on the backburner for me, > that I would gladly accept. One would be to allow users to specify a > different file to use as their config file (this would work especially > well, I think, with an ability to _not_ read the system wgetrc; but > whether this should be in the form of requiring an #include from the > user's if you really want both, or a "no_system_wgetrc = no"-type option > (the former is preferable and comes with other advantages, but there are > backward-compatibility reasons to prefer the latter)). > > The other minor issue is that we currently read-and-process both the > system wgetrc _and_ the user's wgetrc (if they're both available) before > checking the success result from the first one. Meaning that we can, in > some circumstances, be wasting time processing the user wgetrc when we > already _know_ there's a problem with the system wgetrc. > > Here's the relevant reports in the tracker on those: > https://savannah.gnu.org/bugs/index.php?20635 > https://savannah.gnu.org/bugs/index.php?20370 > > - -- > Micah J. Cowan > Programmer, musician, typesetting enthusiast, gamer... > http://micah.cowan.name/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHrn5W7M8hyUobTrERAp8kAJ4vmHeh2eb7z0Icv3HmYUOk8mTjcQCfTU6E > HhlavWRnp8Hd4Azg8G4HCeI= > =1GON > -----END PGP SIGNATURE----- >
