This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Questions about maximum length of file name of eCos RAM file system
- From: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- To: Øyvind Harboe <oyvind dot harboe at zylin dot com>
- Cc: eCos Disuss <ecos-discuss at ecos dot sourceware dot org>, uchida dot s dot 2010 at gmail dot com
- Date: Sat, 27 Feb 2010 03:40:58 +0200 (EET)
- Subject: Re: [ECOS] Questions about maximum length of file name of eCos RAM file system
- References: <c09652431002250201j4997b88cqcd3804326db627c@mail.gmail.com>
On Thu, 25 Feb 2010, Øyvind Harboe wrote about
http://ecos.sourceware.org/ml/ecos-discuss/2010-01/msg00048.html
I don't think there is a filename limit in ramfs as such.
Hello Øyvind,
It seems I found such a limit in ramsf.c:find_entry():
@@ -1339,7 +1356,7 @@ static int find_entry( ramfs_dirsearch *
ramfs_node *dir = ds->dir;
const char *name = ds->path;
const char *n = name;
- char namelen = 0;
+ int namelen = 0;
Then ds->namelen will be negative for the filenames with its length
grater than 2^7. GDB showed me that.
Perhaps you are running into the bug I found.
Try this patch:
http://sourceware.org/ml/ecos-patches/2010-02/msg00017.html
--
Øyvind Harboe
Øyvind, I tried your patch without the above and `ramfs1' test did
hang in a place if I set up that `LONGNAME1' value, for example, as
[sring repeat "1" 128], by other hand, call of stat(), read() fails
for the "long" filenames without your patch (at the least on syntetic
target). So, the both tweaks solve the issue.
Sergei
--
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss