Per Hank:

for our immediate problem, i don’t have a specific theory of causation.
there are multiple possible causes, and we don’t have enough information
to distinguish among them. i would like to try the suggested procedure
(writing to a tmp dir, testing there, then moving the file into the item
dir, even if that entails a copy across filesystems) because

(1) it has diagnostic value, helping us narrow down possible causes based on
    whether the problem recurs,
(2) if at all possible, i want to preserve the practice of moving or
    copying only complete, known-good, files into the item dir, breaking
    that convention as a last resort once we’ve determined it’s the only way
    to resolve this problem.

It looks like we were seeing disks corrupting _meta.xml files in rare
occasions, so let's try extra hard to make sure that what we write to
the disk is what we wanted to write to the disk.

Relates to commit 13bf6707

except that this time the problem occured with XML looking like this:

    <subject>and index</subject>
    <subject>ve thinking</subject>
    <subject>innovations</subject>
    <subject>in educ</subject>
    <subject/>

And it was turned into this:

    >>> m=parse_item_metadata('/tmp/alda0000unse_meta.xml')
    >>> m['subject']
    ['and index', 've thinking', 'innovations', 'in educ', None]

When we encountered items with no value set at all, like so:

  <lcamid/>

Our code tripped when writing the metadata back to _meta.xml format;
because the entry got the value None in Python. Petabox team suggested
to just drop the entry, causing it to be done after the metadata is
writtne back to the item.

Hank wrote:

> yeah, that’s an empty value (same as <lcamid></lcamid>); i would also be fine with just dropping them when encountered—i think some of our tools may do that.

Jim wrote:

> I would just treat it as though it wasn’t set.  I think MDAPI will drop a metadata key if the value is empty, perhaps this was added through some other mechanism.