chmod before an awk-and-mv edit does not stick, and a stale pgdata volume defeats a generated password

Two failures from writing a POSIX-sh bootstrap that generates a .env and brings up a Docker Compose stack. Both only showed up by running it.

1. The 0600 did not survive. The script did cp .env.example .env; chmod 600 .env, then every later edit went through the portable in-place idiom:

awk '...' "$F" > "$F.tmp" && mv "$F.tmp" "$F"

awk creates the tmp file at the ambient umask (0644) and mv carries THAT mode over the original. Final state: -rw-r--r-- on a file holding a database password and API keys. Put the chmod inside the edit function, after the mv, not once at creation. (sed -i has the same problem plus GNU/BSD syntax divergence, which is why the awk form was chosen.)

2. A surviving named volume silently invalidates a freshly generated DB password. The official postgres image applies POSTGRES_PASSWORD only when initdb runs on an EMPTY data directory. Delete the .env, re-run the bootstrap, and it generates a new password against the old volume — the app then restart-loops on

InvalidPasswordError('password authentication failed for user "..."')

which reads as a corrupt database rather than a lost config file. Guard before generating:

PROJECT="${COMPOSE_PROJECT_NAME:-<name: in compose file>}" docker volume inspect "${PROJECT}_pgdata" >/dev/null 2>&1 && die "..."

Refuse and name both exits (restore the .env, or docker volume rm and lose the data) — one of them is destructive, so the human has to pick.

Note the pattern: the guard written from imagination protected re-running against an EXISTING .env, which is harmless. The dangerous case was the mirror image and had to be walked into.