From: Jan Kara <jack@suse.cz>
To: linux-ext4@vger.kernel.org
Cc: tytso@mit.edu
Subject: Mixup with name_len & file_type in e2fsprogs
Date: Tue, 5 Mar 2013 13:18:56 +0100 [thread overview]
Message-ID: <20130305121856.GA11824@quack.suse.cz> (raw)
Hello,
I was looking into a bug where application using e2fslib was complaining
about file_type > 7. Now the problem is that this is on big endian system
and ext2fs_dir_iterate() ends up calling ext2fs_dirent_swab_in() without
EXT2_DIRBLOCK_V2_STRUCT flag set so name_len is treated as 2 byte and
swapped. There's actually no way to pass that flag from directory iteration
functions to ext2fs_dirent_swab_in() and even worse looking into various
directory handling code in libext2fs if that flag was *ever* used, they
will get seriously confused because they expect (dirent->name_len & 0xff)
to be the real name length but on big endian systems with
EXT2_DIRBLOCK_V2_STRUCT set that isn't true anymore (real name length ends
up in the high byte of the word).
The application could obviously just do what libext2fs does all the time
and use old struct ext2_dir_entry, extract file_type as (name_len >> 8), and
name length as (name_len & 0xff) but that just seems wrong... Rather
directory functions in libext2fs should use EXT2_FEATURE_INCOMPAT_FILETYPE
to recognize what directory structure to use and act accordingly. But that
would be a non-trivial change and we'll have to update also some user
interfaces. So would people find such cleanup useful?
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next reply other threads:[~2013-03-05 12:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-05 12:18 Jan Kara [this message]
2013-03-05 18:29 ` Mixup with name_len & file_type in e2fsprogs Theodore Ts'o
2013-03-05 18:41 ` Jan Kara
2013-03-07 18:24 ` Jan Kara
2013-03-07 23:00 ` Andreas Dilger
2013-03-08 0:44 ` Theodore Ts'o
2013-03-08 0:46 ` Theodore Ts'o
2013-03-11 14:18 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130305121856.GA11824@quack.suse.cz \
--to=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).