[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] Contribution on bug #45037
From: |
Tim Rühsen |
Subject: |
Re: [Bug-wget] Contribution on bug #45037 |
Date: |
Sun, 17 May 2015 12:55:18 +0200 |
User-agent: |
KMail/4.14.2 (Linux/4.0.0-1-amd64; KDE/4.14.2; x86_64; ; ) |
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.