This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones
- From: Jeff Law <law at redhat dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Eric Gallager <egall at gwmail dot gwu dot edu>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 22 Jul 2016 16:28:18 -0600
- Subject: Re: [PATCH, contrib] download_prerequisites: check for existing symlinks before making new ones
- Authentication-results: sourceware.org; auth=none
- References: <AM4PR0701MB216261B83CC541C86A89794AE4090@AM4PR0701MB2162.eurprd07.prod.outlook.com>
On 07/21/2016 12:15 PM, Bernd Edlinger wrote:
Agreed. And naturally the question is do we bother to check the return
code from the rm -f? I think we should and exit with an error if it fails.
> So rather than relying on ln to remove the link, why don't we just
> explicitly remove it with rm -f?
sounds good, I ran into similar issues already.
ln -nfs does not follow the target if it is a symlink
treat LINK_NAME as a normal file if it is a symbolic
link to a
but I think a simple rm -f will do as well, and avoid potential
However wget has a similar issue, if the $MPFR.tar.gz file is already
there, maybe incomplete, the wget chooses a new name, so I'd suggest
to rm -f that file as well, and the whole $MPFR subtree while you are