Opened 6 years ago

Last modified 6 years ago

#10991 reopened enhancement

readdir (dirent.h) does not have d_type

Reported by: waddlesplash Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/POSIX Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by anevilyak)

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

Change History (9)

comment:1 by pulkomandy, 6 years ago

Description: modified (diff)

" not supported by all filesystem types"

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

comment:2 by anevilyak, 6 years ago

Description: modified (diff)
Resolution: invalid
Status: newclosed


comment:3 by axeld, 6 years ago

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.

comment:4 by waddlesplash, 6 years ago

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).

comment:5 by pulkomandy, 6 years ago

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.

comment:6 by pdziepak, 6 years ago

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.

comment:7 by waddlesplash, 6 years ago

Milestone: R1Unscheduled
Resolution: invalid
Status: closedreopened

Yes, that's how Linux does it IIRC.

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

comment:8 by bonefish, 6 years ago

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

comment:9 by korli, 6 years ago

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).

Note: See TracTickets for help on using tickets.