Hi:
My understanding of the resource managers is that uid/gid information is
stored in an ‘attribute’ structure that exists for every resource/device;
while an ‘OCB’ structure exists for every fd, in that device.
However, for a file system, you would need uid/gid for each file (fd). How
does the QNX4 FS resource manager, manage to store uid/gid information for
each fd?
Help would be greatly appreciated.
-Rommel
Rommel Dongre <rdongre@pillardata.com> wrote:
Hi:
My understanding of the resource managers is that uid/gid information is
stored in an ‘attribute’ structure that exists for every resource/device;
while an ‘OCB’ structure exists for every fd, in that device.However, for a file system, you would need uid/gid for each file (fd). How
does the QNX4 FS resource manager, manage to store uid/gid information for
each fd?
Why? A file on a disk is effectively an attribute structure. Do an “ls -l”
and you’ll see exactly one uid and gid for the file… The attribute
structure is for the file, the OCB is for the file descriptor…
The trick to a filesystem is that you want to cache the attributes structures;
if you have 1 million files on disk, you certainly don’t want to have one
million attributes structures in memory – you want to limit yourself to some
number…
Help would be greatly appreciated.
-Rommel
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Rommel Dongre <rdongre@pillardata.com> wrote:
Hi:
My understanding of the resource managers is that uid/gid information is
stored in an ‘attribute’ structure that exists for every resource/device;
while an ‘OCB’ structure exists for every fd, in that device.However, for a file system, you would need uid/gid for each file (fd). How
does the QNX4 FS resource manager, manage to store uid/gid information for
each fd?
File descriptors do not represent files, they represent a
client connection to a file. Attributes represent a single
file (which may have many connections to it).
-client fd maps to a server ocb which points to an attribute.
-In general one attribute instance per file with access
control information/rules.
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Core OS Technology Group
(613)-591-0931 http://www.qnx.com/
Rommel Dongre <rdongre@pillardata.com> wrote:
Hi:
My understanding of the resource managers is that uid/gid information is
stored in an ‘attribute’ structure that exists for every resource/device;
while an ‘OCB’ structure exists for every fd, in that device.
The thing to remember is that a FILE on the disk is another
resource/device.
An OCB exists for each unique open() call made on the client
side – they correspond (mostly, barring dup()s) to file descriptors
in clients. They do not represent things on the device, rather they
can be thought of as a pointer to something on a device.
The OCB structure used by the resource manager library does have
a pointer to an attribute structure of the device/file that was
opened.
So, OCB will include per-open data, including things like current
read/write offset (seek location), open mode (O_RDONLY, O_RDWR),
etc.
The attribute structure will contain information about the file,
including things like: access, modification and status change
times, ownership (uid, gid), permission (-rw-rw-rw-, or 0666),
etc.
iofunc attribute structures are structures of information about
files and/or directories and/or devices.
ocbs are structures of information about client’s opens.
Yes, this can be a bit confusing.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.