README.md

@@ -197,14 +197,20 @@ After an unclean kill or a power cut a hidden `.track.mp3.XXXXXX` can survive.
 It is not playable, it is not in the source, and the next run's `--delete`
 removes it.
 
-The real risk is not rsync's, it is the filesystem's: FAT32 has no journal, so
-buffers that never reach the card are corruption. The script therefore traps
-`INT` and `TERM` and still flushes and unmounts on the way out, exiting 130.
-Both the normal path and the interrupt path call the same function, so they
-cannot drift apart.
+Interrupting does not, by itself, endanger the filesystem. The kernel flushes
+dirty pages within `dirty_expire_centisecs` — thirty seconds by default — and
+`umount` always syncs before it returns. Losing data needs you to interrupt,
+*and* pull the card inside that window, *and* skip the unmount.
 
-The one case nothing can help with is pulling the cable or the card mid-write.
-Wait for the unmount.
+The script still traps `INT` and `TERM` and flushes and unmounts on the way
+out, exiting 130. Not because a Ctrl-C is dangerous, but because it removes the
+manual step and makes the exit deterministic — you get the same "safe to
+disconnect" either way, rather than having to remember which path you took.
+Both paths call the same function, so they cannot drift apart.
+
+What genuinely does lose data is pulling the cable or the card without
+unmounting at all, interrupted or not. FAT32 has no journal. Wait for the
+unmount line.
 
 ### Making it faster over a network mount