Explanation

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.

Still stuck?

Find the project on Tangled at tangled.org/byjp.me/atfs. Open an issue there. Include the contents of LAST_FATAL_ERROR.md, if you have this file, and which board you run.