On Fri, Mar 15, 2013 at 10:05 PM, Greg Martin <[email protected]> wrote: > In all Unices I've used the behavior for unlink is to mark a file for > deletion when no file descriptors reference it. However, in using a UNIX > socket with nodejs I have found that calling unlink after the socket is > created causes it to be deleted immediately. This means to delete the socket > the process on exit handler must be used. Should it fail to get called the > socket won't be deleted. IT seems to me this is a bug in fs.unlink's > behavior. > > -Greg.
Your description of how unlink() works is incorrect. You're confusing directory entries with inodes. UNIX sockets are file system entities. When you unlink() a file system entity, its directory entry is removed (subject to permission checks, of course), making it inaccessible to subsequent file system operations. A directory entry points to an inode. That inode has a reference count that roughly corresponds with the number of open file descriptors. As long as the reference count > 0, the resources associated with the inode are not reclaimed. That's why you can keep reading from or writing to a file that's been removed by another process, provided you had it open at the time of deletion. But you cannot open it again - its directory entry is gone. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
