readdir (dirent.h) does not have d_type

[waddlesplash]

​http://man7.org/linux/man-pages/man3/readdir.3.html

I understand this is not an official POSIX thing but rather a Linux thing; still, many applications use it and we should support it.

[pulkomandy]

" not supported by all filesystem types"

The docs for this even explains why it is a bad idea. Fix the apps instead.

[anevilyak]

Indeed.

[axeld]

It's a bad idea to rely on it, but there is no reason that Haiku could not support it -- most file systems should be able to support it properly.

The only problem I see is with binary compatibility. We could reuse the extra query fields, though, but that would mean they have a different meaning for queries and directory listings.

However, I'm not sure it's worth the trouble, unless you have a good example of what kind of optimization this feature allows for.

[waddlesplash]

Most usages of this that I saw were just using it to test for directories. Which all filesystems support -- so at least some functionality of it can be done that way.

I say we implement this as part of R3 (where we break binary compatibility).

[pulkomandy]

The problem is not supporting directories. The problem is this struct is something you get by reading only the information in the parent directory. Some filesystem have a marker there to know what the filetype is, but others do not, and for those, you need to follow the directory entry to the target node in order to get the information. And there is already a way to do that: it's stat().

If you implement this, it will make readdir() much slower on these filesystems, because instead of reading just the directory, all the files contained in it will also need to be stat'ed to get the information. Or we could always return DT_UNKNOWN, but that's not useful in any way.

[pdziepak]

I don't see any problems here. If the filesystem supports d_type then everyone is happy and the application after one syscall gets types of multiple files. If d_type is not supported DT_UNKNOWN is returned and app has to call stat for all files it is interested in, exactly like it has to do now. What's wrong with that?

The only real obstacle to adding this filed is, as Axel said, binary compatibility.

[waddlesplash]

Yes, that's how Linux does it IIRC.

Switching to "Unscheduled" as this will be at least after R1 due to breaking binary compatibility.

[bonefish]

At a first glance I don't see any binary compatibility issue that we cannot solve via symbol versioning.

[korli]

It would be nice to know at least a few from the many applications affected by this bug (to be able to build and check them at HaikuPorts).