<LAVA_DISPATCHER>2011-11-29 08:12:58 AM INFO: Downloading the http://snapshots.linaro.org/oneiric/linaro-o-nano/20111128/0/images/tar/linaro-o-nano-tar-20111128-0.tar.gz file using cache
<LAVA_DISPATCHER>2011-11-29 08:22:06 AM ERROR: os.link failed
Traceback (most recent call last):
File "/usr/lib/pymodules/python2.7/lava_dispatcher/utils.py", line 63, in download_with_cache
os.link(file_location, cache_loc)
OSError: [Errno 17] File exists
Looks like there could be a bit of a race if two processes are working on the same image at the same time. If the cache location does not exist when it starts, it will download the file. It then checks again if the cache location exists (well, the directory for it at least), and makes it, then links the download file to it. This is not atomic of course though, so there's a bit of a window where we could see it try to link to something that already exists.
until now, it seems that the cached images are used seldom.
may be it's better to disable the cache function now, and enable it in the
future when the reuse case increase.
On 16 December 2011 23:41, Fathi Boudra <email address hidden> wrote:
> ** Changed in: lava-dispatcher /bugs.launchpad .net/bugs/ 897918 R>2011- 11-29 08:12:58 AM INFO: Downloading the snapshots. linaro. org/oneiric/ linaro- o-nano/ 20111128/ 0/images/ tar/linaro- o-nano- tar-20111128- 0.tar.gzfile using cache R>2011- 11-29 08:22:06 AM ERROR: os.link failed pymodules/ python2. 7/lava_ dispatcher/ utils.py" , line 63, file_location, cache_loc) /bugs.launchpad .net/lava- dispatcher/ +bug/897918/ +subscriptions
> Milestone: 2011.12 => 2012.01
>
> --
> You received this bug notification because you are a member of Linaro
> Validation Team, which is subscribed to LAVA Dispatcher.
> https:/
>
> Title:
> OSError: [Errno 17] File exists
>
> Status in LAVA Dispatcher:
> In Progress
>
> Bug description:
> <LAVA_DISPATCHE
> http://
> <LAVA_DISPATCHE
> Traceback (most recent call last):
> File "/usr/lib/
> in download_with_cache
> os.link(
> OSError: [Errno 17] File exists
>
> Looks like there could be a bit of a race if two processes are working
> on the same image at the same time. If the cache location does not
> exist when it starts, it will download the file. It then checks again
> if the cache location exists (well, the directory for it at least),
> and makes it, then links the download file to it. This is not atomic
> of course though, so there's a bit of a window where we could see it
> try to link to something that already exists.
>
> To manage notifications about this bug go to:
> https:/
>