it appeared to me having a ext3 filesystem generated using the toolchain of the open embedded folks.
the resulting image exposed uncomfortable warnings about illegal inodes to me.
the offered option was to delete all those symlinks. but astonishingly they all worked
for me in a normal testbed environment and even when mounted from a PC based Linux.
after closer inspection of the image and the e2fsck program i came to the assumption
that all those popping up symlinks had a target length of exactly 60 ASCII characters
and that the function e2fsck_pass1_check_symlink from the file e2fsck/pass1.c from
my version, from the latest release and from the topmost version in the git repository
considers such lengths invalid when those embedded in the blocks array of the inode.
my support question right here is:
whats the official definition of the character encoding and max length for such sort of data embedding?
the text contained there is length encoded as i_size is used for encoding its length.
i know about the habit of some c-coders to still add a trailing zero in such setups.
and it might be the case that either a trailing zero is obligatory or its not needed.
the relevant check sequence from e2fsck looks like this with zero meaning an error:
if (inode->i_size >= sizeof(inode->i_block))
len = strnlen((char *)inode->i_block, sizeof(inode->i_block));
if (len == sizeof(inode->i_block))
if (len != inode->i_size)
other sources are quite un-precise or even contradicting each other:
18.104.22.168. Symbolic link
As stated before, if the pathname of a symbolic link has up to 60 characters, it is stored in the i_block field of the inode, which consists of an array of 15 4-byte integers; no data block is therefore required. If the pathname is longer than 60 characters, however, a single data block is required.
Symbolic links are also filesystem objects with inodes. For all symlink shorter than 60 bytes long, the data is stored within the inode itself; it uses the fields which would normally be used to store the pointers to data blocks. This is a worthwhile optimisation as it we avoid allocating a full block for the symlink, and most symlinks are less than 60 characters long.
i need to know that because this decides which part of software i want to fix - either the checker or the image generator tool.
either the 60 character strings are valid for beeing stored in this block area or they are not. (the second option looks a little bit like space wasting to me.)