FS: problems and patches

Dmitry Kargapolov dk at gentex.ru
Thu Nov 30 18:55:00 UTC 2000


Hello All.

I have solved the problem with path evaluation of the
directory entry that is mounting point for other
file system. This problem was discussed in previous
messages by Sergei Organov and rtems society.
Look at the patch imfs_eval.c.diff.
It works properly in my tasks. (For testing my
own FS mounted to IMFS directory I use ported
from Midnight Commander mcserver).

Also it seems to me that when open a directory,
search permissions must be tested.
that's why I offer to consider the patchs open.c.diff
and opendir.c.diff.
(the idea of using flag _O_DIRECTORY come from the linux)

Important Note: I use rtems-ss-20000802.
(the reason was: GoAhead web-server in latest
snapshots has a few bad surprises - it works
slowly, and cuts off eigth bit. May be I have
to do some tuning - I don't know yet...)

There is another problem in RTEMS filesystem.
There is not rename() implementation. So libc does it via
two FS calls: link() and unlink().
It is bad for two reasons. Firstly not all filesystems
have hard links, for example JFFS at the moment.
(I'm porting JFFS to RTEMS now).
Secondly, rename() is not monolithic. What will happen
when system will crash right after link()?
JFFS is filesystem with one-step implementation
of all fs operations. And rename() too.
I think it would be useful to add "rename"
to the list of the filesystem's operations
(type rtems_filesystem_operations_table in libio.h)
and to remake newlib with new rename() function
(see newlib configure flag -DHAVE_RENAME)

the type of new operations table element may
be like this:

typedef int (*rtems_filesystem_rename_t)(
 rtems_filesystem_location_info_t *old_file, /* IN */
 rtems_filesystem_location_info_t *new_dir,  /* IN */
 const char                       *new_name  /* IN */
);

attached file rename_example.c contains my version
of the possible future rename() implementation

sincerely,
Dmitry Kargapolov        void at dr.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imfs_eval.c.diff
Type: application/octet-stream
Size: 479 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20001130/7a879ff2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: open.c.diff
Type: application/octet-stream
Size: 585 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20001130/7a879ff2/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opendir.c.diff
Type: application/octet-stream
Size: 513 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20001130/7a879ff2/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rename_example.c
Type: application/octet-stream
Size: 3190 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20001130/7a879ff2/attachment-0003.obj>


More information about the users mailing list