My linux config and rc files https://git.sommerfeld.dev/dotfiles/atom/etc/lostfiles.ignore.tmpl?h=master 2026-05-13T12:43:39Z 2026-05-13T12:43:39Z sommerfeld sommerfeld@sommerfeld.dev 2026-05-13T12:43:39Z urn:sha1:7771ced1411c3140f5ca17bfe282dc23a949c4a6 lostfiles flags directories whose parent is pacman-owned but the dir itself is not (drop-in dirs like /etc/systemd/{logind,system,user}.conf.d, /etc/systemd/system/getty@.service.d, /etc/pacman.d/hooks). Previous template only emitted tracked files, missing these. Walk each tracked path emitting every ancestor up to /etc, then sort -u. Over-emission of pacman-owned parents (e.g. /etc, /etc/systemd) is harmless: grep -vFx simply finds no match for those lines. 2026-05-13T12:43:39Z sommerfeld sommerfeld@sommerfeld.dev 2026-05-13T12:43:39Z urn:sha1:2026f98babdcdd34c09eb59479a02a5603fc70a2 Upstream lostfiles has no extension mechanism; the weekly report ends up dominated by files this repo intentionally deploys plus host-private files we deliberately don't track plus regenerated GTK caches. Add etc/lostfiles.ignore.tmpl which renders /etc/lostfiles.ignore from two sources: 1. Every file under etc/ in the repo (auto-enumerated at chezmoi-apply time, same find-sort pattern the etc deploy script uses). This keeps the ignore list in sync with what we actually deploy with zero manual maintenance. 2. A static block for: the sudo-i symlink, host-private systemd-networkd units (99-hodor*, 99-mandibles*) which contain WireGuard secrets, the getty@tty1 autologin override which contains the username, and known pacman-hook-generated caches under /usr/lib/{gdk-pixbuf-2.0,gtk-4.0}/. Wrap /usr/bin/lostfiles in lostfiles.service via grep -vFxf, with a fallback when /etc/lostfiles.ignore doesn't yet exist (first deploy).