On 13/03/18 07:47, Chris Johns wrote:
On 13/03/2018 17:18, Sebastian Huber wrote:
On 13/03/18 00:49, Chris Johns wrote:
Set the inode size to 256 to work around a newlib scandir check where a
directory has to have a non-zero size to work. Set the size to greater than
24 bytes, a small dirent size so the allocator in scandir works.
The newlib scandir code should be updated to a more recent scandir from
FreeBSD where these checks have been removed. This change is a work
around to avoid new tools on the release branch.
With this change scandir works on IMFS, RFS and JFFS2.
I cannot find a scandir() test in the fstests for all file systems.
Closes #3332
---
cpukit/libfs/src/jffs2/src/fs-rtems.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/cpukit/libfs/src/jffs2/src/fs-rtems.c
b/cpukit/libfs/src/jffs2/src/fs-rtems.c
index ce84d44470..790929d856 100644
--- a/cpukit/libfs/src/jffs2/src/fs-rtems.c
+++ b/cpukit/libfs/src/jffs2/src/fs-rtems.c
@@ -1512,6 +1512,9 @@ static int jffs2_read_inode (struct _inode *inode)
inode->i_mtime = je32_to_cpu(latest_node.mtime);
inode->i_ctime = je32_to_cpu(latest_node.ctime);
+ if (S_ISDIR(inode->i_mode))
+ inode->i_size = 256;
+
inode->i_nlink = f->inocache->pino_nlink;
mutex_unlock(&f->sem);
This code is from the original JFFS2 support for eCos. Which side-effects has
this i_size change for directories? Why can't you place this hack in
rtems_jffs2_fstat()? This would reduce the impact area of this change.
I did not know the history of the RTEMS wrapper. I just assumed all code in that
file is specific to RTEMS. The change I have makes things consistent. I still
think it is OK?
What do you mean with consistent? I thought this is a hack to make the
Newlib scandir() happy? This i_size is used in several places. How do
you know that you didn't accidentally broke something?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
