All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Wade Cline <clinew@linux.vnet.ibm.com>
Cc: "cmm@linux.vnet.ibm.com" <cmm@linux.vnet.ibm.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: [e2fsprogs] ext2_dir_entry To ext2_dir_entry_2 Casting
Date: Wed, 3 Oct 2012 13:58:31 -0400	[thread overview]
Message-ID: <20121003175831.GC4237@thunk.org> (raw)
In-Reply-To: <506C786B.4080704@linux.vnet.ibm.com>

On Wed, Oct 03, 2012 at 10:39:55AM -0700, Wade Cline wrote:
> >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.
> >
>
> Interesting compatibility issue. Will keep it in mind.

To clarify, the EXT2_FEATURE_INCOMPAT_FILETYPE flag indicates that
there _may_ be file type information in the directory entry (and so
only the low 8 bits of name_len should be considered part of the name
length), but it does not guarantee that it will be present in the high
8 bits of name_len.

If it is not there, then readdir will simply return DT_UNKNOWN in the
d_type field of the directory entry returned by readdir(2).  This is
something all application programs have to be prepared to deal with
--- if they need the file type information, and they get DT_UNKNOWN,
then they will need to stat the file to get the information.

	     	     	      	     - Ted

  reply	other threads:[~2012-10-03 17:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <506B31B7.40405@linux.vnet.ibm.com>
2012-10-02 19:02 ` [e2fsprogs] ext2_dir_entry To ext2_dir_entry_2 Casting Wade Cline
2012-10-02 21:08   ` Theodore Ts'o
2012-10-03 17:39     ` Wade Cline
2012-10-03 17:58       ` Theodore Ts'o [this message]
2012-10-03 18:29         ` Wade Cline
2012-10-03 18:54           ` Theodore Ts'o

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=20121003175831.GC4237@thunk.org \
    --to=tytso@mit.edu \
    --cc=clinew@linux.vnet.ibm.com \
    --cc=cmm@linux.vnet.ibm.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.