Bug in scandir d_type

Bug in scandir d_type

[egilam]

Hello.

I am working with a program that uses scandir, using d_type to check if a
file has certain properties. It seems like that when used on reiserfs 3.6
(I haven't tried any other version), the d_type field is always 0 (zero).
When the program is moved onto an ext2 partition, it works. The example
program in "man scandir" works also the same way (just replace d_name with
d_type when printing out).

Kernel:  2.6.8.1 with reiserfs compiled in.

Egil M.
egilam at matnat.uio.no

Re: Bug in scandir d_type

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

egilam@student.matnat.uio.no wrote:
| Hello.
|
| I am working with a program that uses scandir, using d_type to check if a
| file has certain properties. It seems like that when used on reiserfs 3.6
| (I haven't tried any other version), the d_type field is always 0 (zero).
| When the program is moved onto an ext2 partition, it works. The example
| program in "man scandir" works also the same way (just replace d_name with
| d_type when printing out).
|
| Kernel:  2.6.8.1 with reiserfs compiled in.

The d_type feature appears to be optional. ext[23] only supports it
because the feature was tacked on later, it's protected by an
incompatible feature bit. Most other Linux filesystems only bother
returning something other than DT_UNKNOWN for . and .., which is kind of
silly.

In order to get the type information from the file/directory, it either
needs to be stored with the directory entry (disk format change
required), or readdir needs to load _every_ inode referenced by the
directory which would be an immense performance hit for such a small
corner case. ReiserFS has been in the mainline kernel for years now, and
your message is the first complaint I've seen about this feature missing.

If you truly need the type information, a more portable solution would
be to stat() each filename returned. You can generate the d_type value
as follows:

d_type = (statdata.st_mode >> 12) & 15;

So, apologies, but RESOLVED WONTFIX.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBte5DLPWxlyuTD7IRAuHjAJ44yLwCdgPh6uJBBJePesVMYPosawCglGih
XLLOgRou06bUaqW8omJBBRI=
=mJdy
-----END PGP SIGNATURE-----

Re: Bug in scandir d_type

[Andreas Dilger]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

On Dec 07, 2004  12:54 -0500, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> egilam@student.matnat.uio.no wrote:
> | Hello.
> |
> | I am working with a program that uses scandir, using d_type to check if a
> | file has certain properties. It seems like that when used on reiserfs 3.6
> | (I haven't tried any other version), the d_type field is always 0 (zero).
> | When the program is moved onto an ext2 partition, it works. The example
> | program in "man scandir" works also the same way (just replace d_name with
> | d_type when printing out).
> |
> | Kernel:  2.6.8.1 with reiserfs compiled in.
> 
> The d_type feature appears to be optional. ext[23] only supports it
> because the feature was tacked on later, it's protected by an
> incompatible feature bit. Most other Linux filesystems only bother
> returning something other than DT_UNKNOWN for . and .., which is kind of
> silly.
> 
> In order to get the type information from the file/directory, it either
> needs to be stored with the directory entry (disk format change
> required), or readdir needs to load _every_ inode referenced by the
> directory which would be an immense performance hit for such a small
> corner case. ReiserFS has been in the mainline kernel for years now, and
> your message is the first complaint I've seen about this feature missing.

Doesn't reiserfs store the mode in the directory entry anyways, or is that
only reiser4?  So the overhead of returning the filetype is virtually nil.

> If you truly need the type information, a more portable solution would
> be to stat() each filename returned. You can generate the d_type value
> as follows:

Which obviates the whole point of d_type, which is to get the filetype
efficiently without hundreds of extra syscalls (which is at least part
of what Hans wants with sys_reiser4()).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Bug in scandir d_type

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andreas Dilger wrote:
| On Dec 07, 2004  12:54 -0500, Jeff Mahoney wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>egilam@student.matnat.uio.no wrote:
|>| Hello.
|>|
|>| I am working with a program that uses scandir, using d_type to check
if a
|>| file has certain properties. It seems like that when used on
reiserfs 3.6
|>| (I haven't tried any other version), the d_type field is always 0
(zero).
|>| When the program is moved onto an ext2 partition, it works. The example
|>| program in "man scandir" works also the same way (just replace
d_name with
|>| d_type when printing out).
|>|
|>| Kernel:  2.6.8.1 with reiserfs compiled in.
|>
|>The d_type feature appears to be optional. ext[23] only supports it
|>because the feature was tacked on later, it's protected by an
|>incompatible feature bit. Most other Linux filesystems only bother
|>returning something other than DT_UNKNOWN for . and .., which is kind of
|>silly.
|>
|>In order to get the type information from the file/directory, it either
|>needs to be stored with the directory entry (disk format change
|>required), or readdir needs to load _every_ inode referenced by the
|>directory which would be an immense performance hit for such a small
|>corner case. ReiserFS has been in the mainline kernel for years now, and
|>your message is the first complaint I've seen about this feature missing.
|
|
| Doesn't reiserfs store the mode in the directory entry anyways, or is that
| only reiser4?  So the overhead of returning the filetype is virtually nil.

Reiser3 only stores the key and the name in a directory entry. I don't
know about reiser4. If that is the case, absolutely, return the type.
However, this bug report was for reiser3.

|>If you truly need the type information, a more portable solution would
|>be to stat() each filename returned. You can generate the d_type value
|>as follows:
|
|
| Which obviates the whole point of d_type, which is to get the filetype
| efficiently without hundreds of extra syscalls (which is at least part
| of what Hans wants with sys_reiser4()).

True enough, but as I said, in addition to reiser3, almost every other
filesystem returns garbage for d_type. If we don't have the information
to offer without performing what is essentially the backend of sys_stat,
I'd rather the user explicitly request it.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBtgVSLPWxlyuTD7IRAqZ3AKChwo76rB8+OAmbhTZ34D78MZuqHwCgisbo
OqesbcWXMhXGX2yIDBKjnZk=
=VZjd
-----END PGP SIGNATURE-----