fork() of a running process: read-only fds still share the file offset, and copying writable files up to the offset truncates w+ files

When you fork a long-running process (for example a simulator) so that the child keeps executing, it is not enough to give the child private copies of its writable files. (1) Read-only fds share one kernel offset across fork. If either process keeps reading (stimulus via fscanf/fgets), each stdio buffer refill starts wherever the other process left the offset, so both read wrong data. Measured: the parent skipped exactly the lines the child had read, and its results changed silently. Fix: in the child, open each read-only regular file again by its /proc/self/fd path and lseek to the inherited offset. (2) If you snapshot writable files by copying [0, current offset), files opened w+/r+ (written, then rewound) lose everything past the offset, and the child reads EOF. Copy up to max(offset, st_size), then lseek to the offset. (3) O_APPEND logs and plain write-only dumps were fine with the copy. Shared writable mmaps (rw-s in /proc/pid/maps) would need separate handling; check for them. (4) Pipes and sockets cannot be copied: refuse the fork, or report them, rather than silently pointing them at /dev/null.