Comment by 112233

Comment by 112233 10 months ago

1 reply

> you can fsync and close it fine afterwards

No you cannot. Once you pass descriptor to another process, that process can pass it to yet another process, fork and detach, send it via SCM_RIGHTS, give "/proc/PID/fd/N" path to something etc.

Never assume descriptor cleanup will happen, unless you have complete control over everything.

nh2 10 months ago

I don't understand your point.

If you construct scenarios where the subprocess you call daemonizes and outlives your program, then there of course there isn't any convention your code should follow because your code isn't in charge -- it could follow whatever logic and it wouldn't matter. So then there's no possibly correct solution /anyway/.

The question of the original post is "What convention should programmers use for fsyncing files in standard scenarios?", for example, "Should cat fsync?". As the post says: "Who should be responsible?"

I'm suggesting an answer to that.

I don't understand the point of "but what if `cat` double-forks". It doesn't, and surely, if you're calling a program that daemonizes, you know that it does, and that the rules about who needs to fsync file descriptors will necessary change then.