stat() on readdir entries returns the same size and type for every file

[iNeeedIt]

🏷️ Discussion Type

Bug

Body

I hit this while writing a small ls clone and it took me a while to see it, so I'm posting it with the fix in case someone else runs into it.

The program lists a directory with readdir and prints the size and type of each entry with stat:

#include <stdio.h>
#include <dirent.h>
#include <sys/stat.h>

int main(int argc, char **argv)
{
const char *dir = argc > 1 ? argv[1] : ".";
DIR *d = opendir(dir);
struct dirent *e;
struct stat st;

if (!d)
{
    perror(dir);
    return (1);
}
while ((e = readdir(d)) != NULL)
{
    stat(e->d_name, &st);
    printf("%-20s %8lld %s\n", e->d_name, (long long)st.st_size,
        S_ISDIR(st.st_mode) ? "dir" : "file");
}
closedir(d);
return (0);

}

With no argument it works fine. But with another directory, every entry gets the same values:

$ ./a.out demo
. 4096 dir
sub 4096 dir
.. 4096 dir
a.txt 4096 dir
big.bin 4096 dir

a.txt is 12 bytes and big.bin is 5000, so the sizes are clearly wrong. It compiles with -Wall -Wextra -Werror without any warning.

Guidelines

• I have read and understood this category's guidelines before making this post.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[willtechdev]

@iNeeedIt e->d_name is just the file name, relative to demo, but stat() resolves it from the current directory. So the call fails with ENOENT, and since the return value isn't checked, st keeps whatever was there before (here, the values from an entry that happened to exist in .).

Use fstatat() with the directory's fd, so the name is resolved inside demo, and check the result:

#include <fcntl.h>

if (fstatat(dirfd(d), e->d_name, &st, 0) == -1)
{
    perror(e->d_name);
    continue;
}

Tested with your demo: a.txt shows 12 and big.bin 5000.

Docs: https://man7.org/linux/man-pages/man2/fstatat.2.html

If this solves it, please mark it as the answer so others can find it.

[varsh23-p]

Root Cause & Complete Fix — stat() with readdir() on a Non-Current Directory

Great self-answered question! This is a subtle but common C bug. Here's a full breakdown of why it happens and all the ways to fix it.

---

Why It Goes Wrong

e->d_name is just the bare filename (e.g., "a.txt"), not a full or relative path from your working directory. When you call:

c
stat(e->d_name, &st);  // resolves "a.txt" from CWD, NOT from "demo/"

It tries to stat ./a.txt — which doesn't exist. stat() returns -1 (ENOENT), but since the return value isn't checked, st keeps the stale values from the last successful call — which happened to be the . or .. entry of the current directory (hence everything showing 4096 dir).

It works fine without an argument because then the target directory IS the current directory, so bare names resolve correctly.

---

Fix 1 — fstatat() with the directory fd (Recommended)

c
#include <fcntl.h>
// Inside your loop:
if (fstatat(dirfd(d), e->d_name, &st, 0) == -1) {
    perror(e->d_name);
    continue;
}

fstatat() resolves the name relative to the open directory's file descriptor — no path building needed, and it's race-condition safe.

---

Fix 2 — Build the Full Path (Portable)

c
char path[4096];
snprintf(path, sizeof(path), "%s/%s", dir, e->d_name);
if (stat(path, &st) == -1) {
    perror(path);
    continue;
}

Simple and portable. Just make sure your buffer is large enough (or use dynamic allocation for production code).

---

Complete Fixed Program (using fstatat)

c
#include <stdio.h>
#include <dirent.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char **argv)
{
    const char *dir = argc > 1 ? argv[1] : ".";
    DIR *d = opendir(dir);
    struct dirent *e;
    struct stat st;
    if (!d) { perror(dir); return 1; }
    while ((e = readdir(d)) != NULL) {
        if (fstatat(dirfd(d), e->d_name, &st, 0) == -1) {
            perror(e->d_name);
            continue;
        }
        printf("%-20s %8lld %s\n",
            e->d_name,
            (long long)st.st_size,
            S_ISDIR(st.st_mode) ? "dir" : "file");
    }
    closedir(d);
    return 0;
}

---

Key Lessons

Mistake | Fix -- | -- stat(e->d_name) — resolves from CWD | Use fstatat() or build full path Not checking stat() return value | Always check — stale st is silent and misleading -Wall -Wextra won't catch this | The code is valid C; the bug is purely logical

The -Wall -Wextra -Werror flag set won't catch this because the code is syntactically correct — the bug is purely in the path resolution logic.

Hope this helps anyone else hitting the same wall! 🔧