Patch to avoid circular link problem with downloads

[Yann E. MORIN]

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