information in "/var/tmp/tmp/uploads/repub" automatically "times out"

This is the flip side of a problem I was skyping with Paul about earlier today. Both cases are about a mismatch between the item's repub_state and the state of its temporary RePublisher directories in /tmp/tmp on the datanode.

In the other case, the tmp directory was present because someone had previously begun RePublishing the item, but the repub_state had been reset from 3 to 1 because the item was sent through the preprocessor again. Trying to check it back out produced an error because the checkout script doesn't expect an item, once checked out, to go back to repub_state 1. I recommended fixing it by changing the repub_state back to 3; the checkout script should then allow the item to be re-checked out.

This case is the opposite: the tmp directory is no longer there, but the checkout script still expects to find it because the item's repub_state is 3. This one should be fixable by changing the repub_state to 1. The script will then think it was never checked out before, and will allow the "initial" checkout.

In both situations, the repub_state and the tmp dir were saying two different things about whether the item had previously been checked out for RePublishing, and both can be fixed by changing the repub_state to be consistent with the state of the tmp dir: 1 if there is no tmp dir, 3 if there is.

So our first attempts with these fixes did not work.

Case studies: georgemosse00reel116 and hansfroehlich01reel13

What we noticed is that when you switch from repub_states 1 to 3 (or vice versa) it just produces the opposite issue.
Here's what happened:

- We started out with: "The directory /var/tmp/tmp/uploads/repub does not exist on ia331208.us.archive.org"
- We changed the repub_state to 1
- Which gave us this error in OBF: "This item has already been checked out by <email address hidden>! (You are logged in as <email address hidden>)"
- We changed the repub_state to 3
- Which gave us this error, again: "The directory /var/tmp/tmp/uploads/repub does not exist on ia331208.us.archive.org"

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.