Comment 3 for bug 611487

Okay, sorry about sending you off with an incomplete solution last time. The steps I recommended did get you past the *first* set of errors, but still left you prey to another error that's encountered one layer deeper - the one that Dan identified as being due to the /var/tmp/tmp/uploads dir being emptied periodically.

There are *two* relevant tmp directories. Last time I was talking about /var/tmp/tmp/RePublisher-{$id}; that's the dir that's created by RePublisher-checkout.php, and whose presence or absence has to be in sync with the repub_state in order to avoid errors from that script. But once RePublisher-checkout.php is happy, and passes you along to RePublisher-mflm.php, then the second tmp dir comes into play: /var/tmp/tmp/uploads/repub/. That gets created by the preprocessor book-op, and if it doesn't exist, RePublisher-mflm.php fails.

So long as the preprocessor has been run on *any* item located on a given datanode within the past 7-10 days, the dir will still exist. But if it's been longer than that, the dir is no longer there and RePublisher-mflm.php can't run.

The easiest way to re-establish that directory if it's already been deleted is to kick off the preprocessor again. It will redrow because the item already has scandata and proxies, but not until *after* it recreates the dir we need, as that's the first thing it does. So the book-op will redrow, but it can then be deleted or passed:

http://www.us.archive.org/log_show.php?task_id=59653280

Because it'll fail before making any changes to the item or its metadata, this should work without requiring any further cleanup afterward; it's just a little inelegant.

I've done this for georgemosse00reel116 and hansfroehlich01reel13 - they should be ready to go, so long as their repub_state is in sync with the presence/absence of the /var/tmp/tmp/RePublisher-{$id} dir. That covers datanodes ia341310 and ia341340

Items on other datanodes with the same problem (like paulschrag00reel01, on ia331208) will still need the same treatment.

Meanwhile, for a more general solution, yes, it might be a good idea to put this directory somewhere that isn't subject to frequent cleanup sweeps.