On Fri, Jun 25, 2010 at 10:06:41AM -0400, Greg Troxel wrote: > > >> Have you looked at posix to see if it speaks to this? I don't think it > >> gets specific enough to say.
I can't actually find any discussion of this (dumb) behavior anywhere but in the bind(2) manual page. However, it looks like it's probably been described there since 4.2BSD (I don't have the actual 4.2BSD manual pages handy but it is in both the SunOS 4 and 2.10BSD pages). > I don't know, and if you've got an argument that code written for either > behavior will be ok both places I don't have a problem with it. The > only thing I can think of is that code that does an explicit unlink and > checks for error on the unlink may complain, which is pretty mild. Code written to not unlink wouldn't be OK on systems that require the unlink. But code written to do the unlink would continue to work anywhere -- it will just work better now, in that if it exits early (and, you know, programs do tend to do that ;-)) the file will go away from the filesystem, rather than sitting there as a riddle for whatever person or process is left to clean it up. I could make this a socket option. I'm just wondering if I really should. Changing the default behavior seems very appealing to me because it would actually retroactively "fix" buggy old programs with almost no downside. Thor
