This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Andy, All, On Tuesday 15 June 2010 18:21:53 Andy Gibbs wrote: > In my configuration, I'm saving the downloaded files to a local directory, > but crosstool seems to sometimes get out of sync with itself when restarting > again later. The outcome was that the files in the saved downloads folder > were becoming circular links. > > It took a little while to work out what was happening: crosstool was > ordinarily downloading the file to the tarballs folder, then deleting the > file in the saved downloads and creating a link from there to the tarballs > folder. Where it went wrong was if something caused the download to fail (I > didn't manage to track exactly why this happened, sorry!), but there was > still the link from the tarballs folder to the saved downloads folder from a > previous time. This was then being moved to the saved downloads folder and > thus causing the circular link. > > I hope this description makes sense!!! I see what you mean, but I don't understand how it can happen. Say 'savedir' is the place you tell crosstool-NG to save downloads. And 'tardir' is where we store tarballs for building. Then, if configured to save tarballs, what crosstool-NG basically does is: - look in 'tardir' to see if a tarball exists (real file, or symlink): - if so: - stop - look in 'savedir' to see if a tarball already exists and is readable: - if so: - link that tarball from 'savedir' into 'tardir' - stop - try to retrieve a tarball from the listed URL, and store it in 'tardir' - if it succeeds: - remove an existing tarball in 'savedir' - move the tarball from 'tardir' into 'savedir' - link that tarball from 'savedir' into 'tardir' Thus, I can't see how a symlink in 'tardir' could be moved to 'savedir'. The only issue that may be left is with the first test, where readability is not verified, but again, I don't see it failing in the way you described. > Anyway, the attached patch provides an easy work-around. What the patch > does is changes how the CT_SaveLocal function works. Instead of always > moving the file from the tarballs directory to the saved downloads > directory, it first checks to see whether the file is actually already the > link to a file in the saved downloads directory. Only if it isn't will it > then do the swap. I've used the 'readlink' function in order to correctly > determine the path both of the file and the target folder in order to expand > out all symbolic links and any '..'s and ensure a proper comparison. I feel uneasy with that patch. I'd rather that you point to a way I can reproduce that symlink-loop-of-death, because I'm really don't see how that can happen... But it's late, and I may not be sentient enough tonight to be sure I did not miss anything... Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |