lkml.org 
[lkml]   [1998]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.245 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site