Hello,
where can I get definition of the DIR structure? There is only symbolic definition in the <dirent.h>:
typedef struct _dir DIR;
but the definiton of struct _dir doesn’t seem to be public.
Thanks!
Jan
Jan Ptacek <ptacek@esys.cz> wrote:
where can I get definition of the DIR structure?
There is only symbolic definition in the <dirent.h>:
typedef struct _dir DIR;
but the definiton of struct _dir doesn’t seem to be public.
It is an opaque type that you do not / should not need to know. The
access to directory contents via opendir()/readdir()/closedir() does
not need to expose the internal representation/implementation …
Is there a reason for wanting to know this detail?
On 4 Jun 2002, John Garvey wrote:
Jan Ptacek <> ptacek@esys.cz> > wrote:
where can I get definition of the DIR structure?
There is only symbolic definition in the <dirent.h>:
typedef struct _dir DIR;
but the definiton of struct _dir doesn’t seem to be public.It is an opaque type that you do not / should not need to know. The
access to directory contents via opendir()/readdir()/closedir() does
not need to expose the internal representation/implementation …Is there a reason for wanting to know this detail?
In my QNX4 application i used dd_fd member of the DIR structure to
directly pass IO messages on.
Jan.
Jan Ptacek <ptacek@esys.cz> wrote:
On 4 Jun 2002, John Garvey wrote:
where can I get definition of the DIR structure?
It is an opaque type that you do not / should not need to know. The
Is there a reason for wanting to know this detail?
In my QNX4 application i used dd_fd member of the DIR structure to
directly pass IO messages on.
Ah, yes, the exception where knowing this is useful! I have run into
similar problems in a system that needed to configure the directory
into particular output modes prior to doing a readdir() of it. There
is no POSIX requirement that directory access be done on top of an fd,
but of course that is the obvious (and QNX) implementation. But, unlike
QNX4, QNX6 supports a fully unioned pathname space (with multiple
mounts at the same point), so it is not a single fd but rather an
array of fds to every server that is unioned at that directory!
I have often thought that a routine to send a message to every such
fd would be a useful extension, but currently it does not exist. What
IO messages do you need to send to the directory? If it is to toggle
stat detail inclusion/exclusion you can use dircntl() to do this. If
it is to control the output format you can bundle all information in
the server into the reply with a DTYPE* and parse out the relevant
details at the client side with _DEXTRA_FIRST/NEXT processing. Or is
it something else … ?
On 4 Jun 2002, John Garvey wrote:
Jan Ptacek <> ptacek@esys.cz> > wrote:
On 4 Jun 2002, John Garvey wrote:
where can I get definition of the DIR structure?
It is an opaque type that you do not / should not need to know. The
Is there a reason for wanting to know this detail?
In my QNX4 application i used dd_fd member of the DIR structure to
directly pass IO messages on.Ah, yes, the exception where knowing this is useful! I have run into
similar problems in a system that needed to configure the directory
into particular output modes prior to doing a readdir() of it. There
is no POSIX requirement that directory access be done on top of an fd,
but of course that is the obvious (and QNX) implementation. But, unlike
QNX4, QNX6 supports a fully unioned pathname space (with multiple
mounts at the same point), so it is not a single fd but rather an
array of fds to every server that is unioned at that directory!I have often thought that a routine to send a message to every such
fd would be a useful extension, but currently it does not exist. What
IO messages do you need to send to the directory? If it is to toggle
stat detail inclusion/exclusion you can use dircntl() to do this. If
it is to control the output format you can bundle all information in
the server into the reply with a DTYPE* and parse out the relevant
details at the client side with _DEXTRA_FIRST/NEXT processing. Or is
it something else … ?
I need to send all IO messages. The application that i need to port to
QNX6 is directory mirroring IO manager. It backups particular directory
over network to another machine. It works in this way:
The IO manager renames the directory that needs to be mirrored to a
temporary name and registers the original path. When it gets the
_IO_CONNECT messages it calls open()/opendir() in the temporary directory
and gets the fd. Now every subsequent IO message is “doubled” - one is
send to our fd and the copy is saved to circuite buffer. The buffer is
sended from time to time to process on another node that handles
the messages.
So i need to know the fd because you can handle all the messages in the
same way - both the “file” messages and the “directory” messages.
Jan.
Jan Ptacek <ptacek@esys.cz> wrote:
On 4 Jun 2002, John Garvey wrote:
I need to send all IO messages. The application that i need to port to
QNX6 is directory mirroring IO manager. It backups particular directory
over network to another machine. It works in this way:
To reiterate my previous points: this information is not exported, and
may in fact be multiple fds due to the union filesystem.
Now, the only mode you can open a directory is for no access or O_RDONLY,
and a read() on a directory is defined to be a structured readdir()
operation. So you could mirror an “fd” for a shadowed file and a “DIR*”
for a shadowed directory. When you receive a read() on a directory
then you issue it as a readdir() on the shadowed DIR*, a close() becomes
closedir(), and lseek() becomes rewinddir()/seekdir()/telldir(). This
will work for everything except extensions such as fcntl()/devctl()/etc;
but since the original client cannot legally obtain an fd itself on
which to issue such messages, then they will not happen … in other
words, there is nothing that the client can do with a directory DIR*
that you cannot emulate yourself in your server via a shadowed DIR*.
So i need to know the fd because you can handle all the messages in the
same way - both the “file” messages and the “directory” messages.
You will need to differentiate between file/directory targets and perform
the mappings as described above … You presumably need to know this
anyway to use the _RESMGR_FLAG_DIR when putting up the intercept path.