Re: cvs: php4 /ext/standard file.c

SS>> The dangerous part is derived by my reading of SUSv2/v3 which SS>> does not permit differentiating between an interrupted write SS>> (retry feasible) and a full disk (retry might cause SIGXFSZ SS>> to be delivered to the thread). Therefore, I think it is SS>> dangerous to apply such a function to regular files, as it SS>> might terminate your application (the default action for SS>> SIGXFSZ is to terminate the process). Oh. I see. I wonder though why I will want to kill my process any time there's no place to write a file, but well - I guess that's another product of commitee thinking. Doesn't matter now. If so, does it mean that according to this standard, there's no way (except for blocking that SIGXFSZ) to know if any write I attempt won't kill my application? And how programmers are supposed to handle this? What was the thought behind this invention? Can't we just block that signal? Or can we reset errno and check after write if we got ENOSPC? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115