Hi:
I’ve heard a lot on hte newsgroup about handling symlinks by a RM, but I
dont still seem to have the complete picture. This is for a file-system type
of an RM.
Specifically:
-
What is the role of io_open() in resolving symlinks? Should it resolve
the symlink or the target of the symlink? I feel there is a need to do the
former for most operations and the latter for some others (lstat, read,
write)
-
If I to resolve just the symlink in io_open, and the target in a io_read
and lstat; how does it work with write? when i want to write to the target,
I will never be able to do it.
I’m guessing that these are ‘solved problems’, so before I decide which way
to go, I’d lke to find out what’s been tried already.
Thanks in advance,
Rommel
Rommel Dongre <rdongre@pillardata.com> wrote:
- What is the role of io_open() in resolving symlinks? Should it resolve
the symlink or the target of the symlink? I feel there is a need to do the
former for most operations and the latter for some others (lstat, read,
write)
Yes, open must be able to do both (stat versus lstat). You look at the
‘msg->connect.mode’ field of the _IO_OPEN message to differentiate …
if S_ISLNK(msg->connect.mode) then you do not want to follow the link
but should resolve on the link itself (this is an lstat, for example).
Other connection routines (unlink, rename, etc) have semantics that are
specified by POSIX (but should be obvious enough to work out, actually
I think they’re always ‘do not follow’, for example, on unlink you do
not want to follow the link, you want to remove the symlink itself).
Also note that during name resolution any non-terminal symlink must be
bounced back to proc for handling (_IO_CONNECT_RET_LINK), as well as the
‘follow’ case for the final name component.
- If I to resolve just the symlink in io_open, and the target in a io_read
and lstat; how does it work with write? when i want to write to the target,
I will never be able to do it.
You seem to have some confusion regarding a connection message and an
fd/io message. These are two separate phases. It is only during the
connection phase that whether an object is a symlink and whether the
link should be resolved or not arises. Once you’ve set up an fd, then
read/write IO occurs on the underlying object. A normal user open() will
always follow the symlink and get to the target. Or by read/write do you
really mean readlink() and symlink()? These are connection messages in
their own right (refer to ‘readlink’ and ‘link’ of resmgr_connect_funcs_t).
I’m certain I have posted a complete summary on how to handle symlinks
in this newsgroup over many months; try threads 2209, 2226, and 2244.
Rommel Dongre <rdongre@pillardata.com> wrote:
Hi:
I’ve heard a lot on hte newsgroup about handling symlinks by a RM, but I
dont still seem to have the complete picture. This is for a file-system type
of an RM.
Specifically:
-
What is the role of io_open() in resolving symlinks? Should it resolve
the symlink or the target of the symlink? I feel there is a need to do the
former for most operations and the latter for some others (lstat, read,
write)
-
If I to resolve just the symlink in io_open, and the target in a io_read
and lstat; how does it work with write? when i want to write to the target,
I will never be able to do it.
I’m guessing that these are ‘solved problems’, so before I decide which way
to go, I’d lke to find out what’s been tried already.
You could look at the source for the ramdisk; AFAIK it now correctly handles
all symlink issues.
http://www.parse.com/free/ramdisk.html
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training, Consulting and Software Products at www.parse.com.