Refine the SIGHUP handling so that the socket isn't closed and re-opened if unnecessary. Concept: move body of the main loop into its own routine, add another loop there with a ReloadConfig exception handler that checks old_config.(listen, port) == new_config.(listen, port) and updates the server.boards dict if true.

Reloading the service fails when the socket is inherited from a service manager. BootServer.server_close closes the socket implicitly. If #7 is fixed this shouldn't occur (because the socket wouldn't be re-created if the socket details hadn't changed), so any fix for this should probably be reverted when #7 is implemented.

Enumeration of the file's chain in FatFile constructor should detect loops (use set and check length against length of map)

FatFileSystem should have read/write properties for dirty and damaged (and dirty should be set+cleared by FAT ops)

The fact port 69 is privileged is the last thing implying nobodd-tftpd needs root privileges. We could implement dropping privileges, but it would be far simpler to just inherit it from systemd/inetd.

Add a tz parameter to FatFileSystem to ensure all decoded datetimes are non-naive (ahead of the deprecation of naive datetimes in future Python). Default to UTC, but document that this should ideally be the local TZ (can we default to local sanely?).

Having used prep for a bit, I've come to the conclusion I've committed the cardinal UNIX sin of doing too much in one tool. It needs splitting up:

• --size can be ditched; fallocate does that just fine anyway
• --copy and --remove can go into something like nobodd-cp and nobodd-rm. Perhaps add an ls and cat clone while at it
• cmdline manipulation should be made more generic; some sort of nobodd-cmdline tool that can "set" var=value (how to delete values?) in the cmdline.txt
• what about config generation? nobodd-cfg? Hmm... need to think about that one

Add usefree parameter to FatFileSystem constructor to override use of the FSINFO block.

We can either raise ENOSPC or return a partial write. Probably worth experimenting with other drivers and seeing what the common behaviour (if any) is.