[[!comment format=mdwn
 username="http://edheil.wordpress.com/"
 ip="99.54.57.201"
 subject="comment 2"
 date="2013-07-27T06:03:55Z"
 content="""
I actually ran through the test I described to you and got the silent failure, but now I'm doing it again and getting the \"Try making some of these repositories available\" error.  (Along with inaccurate \"whereis\" info, as you're seeing there.)  I'm baffled.  Unless something changed with respect to this behavior in the most recent version, which I've installed since then, I don't know what I was doing differently.  Maybe I was confused.

I can guarantee that I was getting silent failures in \"gets\" from my USB drive.  I was \"getting\" \"--from\" my USB drive, nothing was showing up (the symlink was broken), and no error was printed to the console, including the \"try making it available\" one we're getting now.  It's only when I went to the drive and did a \"git annex fsck\" that I realized that those files were actually missing from that remote, and it wasn't just a failure to \"get\" them.  The behavior was alarming enough that I made sure of what was happening before I made the bug report.  I wish I'd actually cut and pasted the demo, instead of just describing it!

It'd still be nice to have some kind of feedback in the assistant (and maybe more understandable feedback in the command line) that something was amiss.  What I would see in the assistant, because of this, is a bunch of queued downloads from the USB drive, but as each one was ready to execute, it would disappear (because it failed) and be replaced by a download from the (lower priority) SSH repo.  This happened a number of times and I found it baffling.

My first instinct in a situation like this is to say \"yeah, I must have been confused\" but I honestly did check this out pretty carefully before sending it in, so I wonder if a recent update improved matters, perhaps inadvertently?  In any case, I'm glad there's some kind of error right now.
"""]]