Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dir.Iterator doesn't return file-type correctly from getdents64 #5123

Open
courtc opened this issue Apr 21, 2020 · 2 comments
Open

Dir.Iterator doesn't return file-type correctly from getdents64 #5123

courtc opened this issue Apr 21, 2020 · 2 comments
Labels
bug Observed behavior contradicts documented or intended behavior contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library.
Milestone

Comments

@courtc
Copy link

courtc commented Apr 21, 2020

According to the Linux man page for getdents64(2), linux_dirent64.d_type will be DT_UNKNOWN unless the filesystem specifically has support for filling it out. A further os.fstatat--or similar--is necessary for getting the type.

I encountered this issue by attempting to iterate a directory on a FUSE filesystem on Linux.

@Vexu Vexu added bug Observed behavior contradicts documented or intended behavior contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library. labels Apr 21, 2020
@Vexu Vexu added this to the 0.7.0 milestone Apr 21, 2020
@daurnimator
Copy link
Contributor

FWIW this was part of the rabbit hole I started going down in #5016

I have a branch locally where I'm playing with solutions to this.

@Jahaja
Copy link

Jahaja commented May 17, 2020

I think that this, returning Unknown, is a sane default because adding an additional call for each entry in those cases would probably impact performance quite a bit since filesystems without d_type support aren't likely storing that metadata anywhere close.

The common approach seems to be to have an explicit function call on the entry to get the file type that does the stat call if needed.

@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 30, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 6, 2020
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
bibo38 added a commit to bibo38/zig that referenced this issue Dec 19, 2023
When using getdents64() (atleast on Linux), the d_type will be unknown
if the filesystem doesn't support it. In this case a seperate stat
call is necessary to determine the file kind.
This may cause additional overhead (e.g. network filesystem) and can be
disabled by an option.

Fixes ziglang#5123
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior contributor friendly This issue is limited in scope and/or knowledge of Zig internals. standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants