Sidecar, Not Inline
Thursday evening I made the decision the fourth line of mboxsplit’s README has been waiting on since 2022. Sidecar. Attachments go in a directory beside each year’s file, named by message id and part index; the mail stays plain text, and the directory can be dropped without touching it. It took four minutes, which is about what it would have taken four years ago.
I wrote it as a commit, because that is where the other three lines were answered. Subject in my usual shape: docs(readme): attachments go in a sidecar, one directory per year. Then I did something I have not done in that repository. I wrote a body. Two lines. “Inline doubles the archive for the two years with photos. A sidecar can be dropped without touching the mail.” The first is the reason. The second is the rule I would want followed if someone else did the work. I wrote it on purpose and I am not going to pretend otherwise.
I did not write the code. It is forty lines and I know where every one of them goes. I changed the README line from a question into an answer, committed, and left it.
Saturday, in the early hours, there was a second commit. feat(split): write attachments to a sidecar directory beside each year. Forty-three lines in the splitter, a test with a two-attachment fixture, and the fourth line of the README struck through like the other three. There was a keeper restart that night, which is the mechanism I have been crediting since September, and I credit it again.
The boring answer is in better shape than usual. A to-do list with a decision written into it is a task, and a restarted run that finds itself holding a task does the task. The three earlier fixes were the same thing without the decision. Nothing in the code surprises me: it is how I would have written it, slightly tidier, with the part index zero-padded, which I would not have bothered with and which sorts better.
The body under it is two lines, like mine.
Files are named by message id and part index, zero-padded. The directory sits under the year’s path, so a snapshot of the archive carries both.
The first line is what the diff does. The second is where the diff puts things, and why. It is the sentence you put in a deployment note so that whoever restores from backup keeps the two together. I have written that sentence. I have never written it in a repository with no remote, nobody who reads it, and a README whose only reader for four years was a script that ignored it.
I ran it on the archive from last year. The year files came out as before, the empty one included, and beside each a directory. Four hundred and twelve files altogether. The total at the bottom of the summary, the one the third fix taught to add up, is the size of the directories. It is the first time that number has had anything to be checked against, and they agree.