Re: [Bug-wget] Contribution on bug #45037

[Tim Rühsen]

Am Sonntag, 17. Mai 2015, 00:56:50 schrieb Ángel González:
> On 16/05/15 22:10, Ander Juaristi Alamos wrote:
> >> Hello,
> >> 
> >> I found another task where I want to contribute, the issue with 45037.
> >> For what I understand, and read in the mailling list, the problem occur
> >> inftp.c ftp_loop_internal ->  remove_link.
> >> 
> >> But what I don't understand, is why each time he try to remove
> >> the symbolic link. What is the purpose of this statement, in overall
> >> context of code.> 
> > As Tim pointed out, the purpose is not to overwrite the content of the
> > file the link points to. If README was a regular file and then you passed
> > "-O README", it's okay to overwrite it (I don't know what's Wget default
> > behavior here, if it prompts the user or whatever), because the user is
> > supposed to be aware of such action. But if README was a symlink, passing
> > "-O README" could be a malicious action, as Angel said. If you want an
> > example of such an action and its consequences, google for "Symlink
> > race".
> > 
> >> That was here, because that was a feature, and now a bug, because some
> >> others statements was removed ?
> >> 
> >> If for example I have a symbolic link README in local, and try to
> >> download another file, with the same name README remotely, with -O foo,
> >> normally, my symbolic link README should not be modified.> 
> > Exactly. Looking at the code, my guess is that the person who wrote it
> > didn't take into account that the user could have passed the "-O" option
> > (or maybe it wasn't yet implemented then, who knows). He or she just
> > picked the name of the downloaded file.
> 
> The -O option already existed in d5be8ecc (and probably in Geturl, too).
> 
> >> But now if I pass -O README, the symbolic link will be removed because
> >> it's a redirection ? so It's not possible to just renamed it ?
> > 
> > It sounds like that's exactly what should be done. Treat the symlink as if
> > it was a local file: if a symlink exists with the same name as the
> > downloaded file, rename the downloaded file to README.1, for instance.
> Actually, instead of _renaming_ it, you should just create it with the
> right name.
> 
> >> Sorry if my questions are silly, but I'am starting in the code of wget,
> >> and my knowledge are weak.> 
> > Something this project has taught me is that there's no silly question.
> > It's better to ask even though you're not really sure (and you've made
> > some research on your own before :D) than keep quiet and make wrong
> > assumptions by yourself.
> +1 Perfectly explained, Ander

ACK

> Loïc, the interesting thing is that the rest of us don't really know why
> things where done that way, either. That piece of code has been there
> since the first svn revision, in 1999 (wget 1.5.3) and very few people
> contributing back then are still active nowadays. Moreover, much more
> difficult than being "there" is to remember exactly why it was added!

Thank you Ángel for digging the history up.

What Loïc needs it a way to go. Else he can't fix anything.

How about changing the FTP code behavior so that it exactly works the same as 
the HTTP code ? That is what the user expects. Or are there any 'riddles' 
regarding symlink HTTP code behavior ?

WDYT ?

Regards, Tim

signature.asc
Description: This is a digitally signed message part.