On Jun 14, 2004, at 8:11, Jay A. Kreibich wrote: On Fri, Jun 11, 2004 at 10:42:50PM -0700, Jim Magee scratched on the wall: On Jun 8, 2004, at 9:48 AM, Justin Walker wrote: On Jun 7, 2004, at 21:56, Jay A. Kreibich wrote: I have a fairly simple question, but I need a very sure answer. If close(2) is called on the last file descriptor that references a standard file, are dirty pages associated with that file's buffers automatically queued for writing, in a similar manor to sync(2)? Yup. I would modify Justin's answer slightly to say that "if the data was written with the write(2), etc... set of programmatic interfaces, the data will be sync'ed automatically by the update(8) daemon." That's quite a modification, given that it turns his "yup" into a "nope." It doesn't. Jim gave you a bit more information, is all. The answer is still 'yup'. For details see the lengthy 'udpated(8)' man page. But this is not really tied to the close(2) call. As I re-read the question, I realize it might not be clear, but my question is explicitly about the behavior of close(2). I can't depend on update(8), as it is killed by init when it drops the system into single user mode. Yes, I know the docs imply it shouldn't be, but it is. So I need to depend on the close(2) call to queue the dirty pages for writing. That is, as you say, a much different question, to which the answer is 'nope'. The point of being in single-user mode is that nothing happens without your executing it directly. There should be no 'background' jobs running, including 'update'. I also can't sync(1) manually after the system is in single user mode because init will kill my script, as well as everything else. Can you make your process sensitive to the shutdown protocol (catch SIGTERM) and do the close at that point? Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.
participants (1)
-
Justin Walker