Apart from my comments above, this looks fine to me. However, maybe it would be worth adding --remote-data to travis so that it will really test this now that it should be fixed?

@astrofrog - thanks for mentioning remote-data - I forgot to run the tests with that on, and it revealed some important fixes.

As for --remote-data on travis, that probably makes sense - after all, we can probably trust that travis has access to google. It's possible travis has some access restrictions that limit use of the cache directory used in some of those tests... So I pushed up two commits here that should run on travis - the e59d7b1 should use --remote-data and 8f20d4d should just do the non-remote tests. So we'll see what happens.

Assuming the tests pass, I think this is good to go, now.

Looks good to me! Tests are passing, feel free to merge.

Hi @eteq , after I replied to #480, I saw this one. Commit 9b99e08 works too. After deletion, data_urlmap.db and an empty download directory remain.

@pllim - yeah, the data_urlmap.db directory is left because the new name for that file is download_urlmap.db. If you just delete data_urlmap.db after this is merged, it should never come back.

@eteq , thanks for the info. I tried again after deleting ~/.astropy and after I did clear_download_cache this time, only an empty ~/.astropy/cache/download directory remains.

@astrofrog - it appears --remote-data is not working on travis for some reason that is not obvious to me. I'll roll back to the previous commit, merge, and add an issue to investigate how to make this work with travis later.