Manfred Spraul wrote:
Can you call F_REOPEN multiple times, or only once after
open(O_DEFEROPEN)?
If F_REOPEN should support multiple calls, then we need a filp specific
callback:
The FIFO code must send wake-ups when a filp is promoted from O_RDONLY
to O_RDWR, and it doesn't support
de=S_IFREG|0664, st_size=318, ...}) = 0
open("./defines.h", O_RDONLY|O_LARGEFILE) = 6
[ is bad ]
open(path, O_RDONLY|O_DEFEROPEN)= 6
fstat(6, ...) = 0
fcntl(6, F_REALLYOPEN) = 0
is safe (though we do need O_SYMLINK to
or write the disk while a format is in progress?
If so, I accept the need for O_NONE.
Well, nearly all the uses for O_DEFEROPEN seem to be the same as the
uses of O_NONE. Being able to do safe fstat()s without opening the
device, that sort of thing.
The only difference is the current ioctl
try to autosense the format. But I'm
not sure fdformat actually does this -- it was mentioned by someone
during the O_NONE thread, thqat is all I know.
The only difference is the current ioctl behaviour for O_NONE, and the
fact that you can actually open an O_DEFEROPEN fd later.
But those
Jamie Lokier wrote:
They're so similar -- do we really need to very similar different
thingws. If so, let's isolate the orthognal differences and make them
work in all reasonable circumstances. Hence F_REOPEN.
Can you call F_REOPEN multiple times, or only once after
open(O_DEFEROPEN
On Sat, 25 Mar 2000, Jamie Lokier wrote:
This patch, against 2.3.99pre3 (or thereabouts) implements an
O_DEFEROPEN option to open(2).
Why don't you just give O_NONE (value: 3) this behaviour?
Partially because I didn't want to break applications already
using this (IMHO, rather dubious
Matthew Kirkwood wrote:
Why don't you just give O_NONE (value: 3) this behaviour?
Partially because I didn't want to break applications already
using this (IMHO, rather dubious) feature.
Mostly, though, because I wanted to leave the O_RDWR/etc.
permission checks in the open() path, to
are basically orthogonal, though. I don't see
any gain from combining them, especially when that just means
an extra fcntl(F_SETFD) in the cases I want deferred open for.
People who want both can specifc O_NONE|O_DEFEROPEN.
Or did I miss something?
Well, nearly all the uses
Hi,
This patch, against 2.3.99pre3 (or thereabouts) implements an
O_DEFEROPEN option to open(2).
The intent is that programs can avoid stat()/open() races, and
the risk of side-effects to open() (tape rewinding being the
canonical example) by doing open(.., O_DEFEROPEN|etc), fstat(fd
