Why format authorization works this way
You will understand why `ATFS_FORMAT_DRIVES_IF_NOT_ATFS` takes a date, and why the two drives it covers carry different risks.
This page only applies when you deploy to an SD-card device.
The two situations the ATFS_FORMAT_DRIVES_IF_NOT_ATFS setting covers
carry very different costs. The ordinary, low-risk case is a chip that
holds data other than atfs data. You lose nothing when atfs formats this
chip, because the chip held nothing of yours.
Rebuilding atfs’s own unhealthy volume is not low-risk. This action
destroys every file the device served. It also destroys the cryptographic
key that gives the device its network identity. The device then starts up
as a new device, with a new identity. You must recreate from scratch any
configuration record that pointed at the old device. Before you rebuild,
try to recover the chip’s contents, or switch to the SD card’s own
storage with ATFS_DATA_DIR instead.
Warning
Authorizing a rebuild of atfs’s own unhealthy volume destroys every
file and the device’s identity key. The device starts over with a new
identity. You must recreate its dev.atfs.server record by hand.
A date authorizes the format only on the day it names, or the day after. This extra day means you can edit the card late at night without causing problems. The design is deliberate. You never need to remember to remove the setting afterwards.
Note
This setting takes today’s UTC date (YYYY-MM-DD), not true. A value
left in place cannot silently authorize a wipe again weeks later.