Messages in this thread | | | Date | Tue, 4 Aug 1998 10:11:45 +1000 | From | Richard Gooch <> | Subject | Re: Races in open(2) |
| |
Dean Gaudet writes: > > > On Mon, 3 Aug 1998, Bill Hawes wrote: > > > Dean Gaudet wrote: > > > > > Returning ENOENT when the parent exists is not compliant. This is the > > > type of kernel bug that's really annoying for application developers. "Oh, > > > if it's linux then I have to retry my open() in user-space if I get ENOENT > > > because they've got some fancy locking scheme and don't want to spend a > > > few cycles in the kernel being compliant"... > > > > Hi Dean, > > > > You might want to look at a few of the cases more closely before deciding that the > > kernel developers are just being lazy or parsimonious with CPU cycles. The ENOENT > > doesn't mean that the parent directory doesn't exist -- it means that the file that > > _used to exist_ is no longer in this directory, having been renamed or deleted. > > Richard's example did this: > > open (LOCKFILE, O_RDWR | O_CREAT | O_EXCL, S_IRWXU) > > That's creating a file. For file creation the only valid ENOENT response > is for bogus pathnames (i.e. no parent directory). It doesn't matter if > the file used to exist or has been renamed, if LOCKNAME doesn't exist now > then that open call should succeed (modulo access rights/etc).
Yup. Syscalls like these are atomic with respect to the *namespace*. Recently moved files are elsewhere in the namespace: they don't count.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |