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.
