handling errors in 'tahoe get'

[zooko]

I just tried to download a file with

allmydata-tahoe get -u http://localhost:8080 THE_FILE_NAME foo

It said:

THE_FILE_NAME retrieved and written to foo

But the contents of foo are not the contents of the file. The contents of foo are:

[Failure instance: Traceback: <class 'allmydata.encode.NotEnoughPeersError'>:
/usr/local/stow/Twisted-2.5.0/lib/python2.5/site-packages/twisted/internet/defer.py:317:_runCallbacks
/usr/local/stow/Twisted-2.5.0/lib/python2.5/site-packages/twisted/internet/defer.py:507:_cbDeferred
/usr/local/stow/Twisted-2.5.0/lib/python2.5/site-packages/twisted/internet/defer.py:239:callback
/usr/local/stow/Twisted-2.5.0/lib/python2.5/site-packages/twisted/internet/defer.py:304:_startRunCallbacks
--- <exception caught here> ---
/usr/local/stow/Twisted-2.5.0/lib/python2.5/site-packages/twisted/internet/defer.py:317:_runCallbacks
/Users/wonwinmcbrootles/playground/allmydata/tahoe/instdir/lib/allmydata/download.py:373:_got_all_shareholders
]

[warner]

can you retest this with 0.6.0? I think I might have improved something here between 0.5.0 and 0.6.0 . The HTTP response should definitely not be '200 OK', and the 'get' client needs to notice that and avoid writing anything to the target file when that happens (in that case, the body will contain some sort of useful error message).

[zooko]

We're focussing on an imminent v0.7.0 (see ​the roadmap) which hopefully has Small Distributed Mutable Files and also a fix for bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.

[zooko]

We need to choose a manageable subset of desired improvements for ​v0.7.1, scheduled for two week hence, so I'm bumping this one into ​v0.7.2, scheduled for mid-December.

[warner]

I just tested 1.3.0 (actually trunk as of 9ab4aa9016bb65dc), and there's still a problem, but a different one. tahoe get my:unrecoverable LOCAL (on a file with only two shares, using 3-of-10) results in an empty file named LOCAL being created, and an ugly HTML representation of an UnrecoverableFileError being written to stderr. The process exit status is 1.

The two bugs:

• LOCAL should not be created
• the HTML traceback should not be printed, instead "UnrecoverableFileError" and perhaps a short message should be written to stderr

[warner]

Fixed. 931ab76588dab261 stops opening the output file until we get a success response (removing the empty file), and UnrecoverableFileError has been mapped into a nicer human-readable string since maybe 1.4.0 or so.

[davidsarah]

The change in 931ab76588dab261 is to not explicitly close the file on error. But don't open files get implicitly closed on process exit?

​POSIX says they do when exit() is called: "The exit() function shall then flush all open streams with unwritten buffered data." Python will usually call exit().

If I'm wrong, convince me with a unit test :-)

[davidsarah]

Sorry, I misread the diff. The file is not opened if there is an error. A unit test would still be nice, though.

[warner]

a50fdca6ab88e6b0: your wish is my command :-)

[davidsarah]

That was quick. Test looks good.