On 10/02/2012 02:08 PM, Theodore Ts'o wrote:
On Tue, Oct 02, 2012 at 12:02:22PM -0700, Wade Cline wrote:
Hello Theodore Ts'o,
Is there a function similar to ext2fs_dir_iterate2() that will call a hook
function on an ext2_dir_entry_2 structure and not an ext2_dir_entry
structure?
The reason I ask is because btrfs-convert currently tries to do a cast
between the two structures as such:
static int dir_iterate_proc(..., struct ext2_dir_entry *old, ...)
{
...
struct ext2_dir_entry_2 *dirent = (struct ext2_dir_entry_2
*)old;
which works fine on little-endian machines, but breaks on big-endian machines.
The reason why we don't have that function today is because what most
programs (especially inside e2fsprogs) have done is to use the
ext2_dir_entry structure and just simply used (name_len& 0xff) to get
the actual name length, and in the case of e2fsck (which is the only
program which in practice has cared about the file type) to get the
file type by doing (name_len>> 8).
I see. That should work fine, too.
If there isn't, would you be interested in a patch that adds a
function, say, ext2_dir_entry_upgrade(struct ext2_dir_entry *old,
struct ext2_dir_entry_2 *new) that will convert one structure to the
other and take into account the endianness of the machine? This
would be better than just ad-hoc fixing the code in btrfs.
We could do that, but that would mean needing to copy the data
structure somewhere else, which means you would have to allocate
memory for the new data structure, and then you'd have to release that
memory later, etc.
I would think that using (name_len& 0xFF) is a much simpler solution,
and my suggestion is to not depend on the file type in the directory
entry (since there might be some very old ext2 file systems that don't
set the file type), and to use the inode's mode bits as authoratative
for the file type of the inode.
Regards,
- Ted
Interesting compatibility issue. Will keep it in mind.
Thank you for the help.
Sincerely,
Wade
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
