Why file access mode checks disagree across environments

A file descriptor can look readable in one environment and fail in another because access mode bits, descriptor flags, and the behavior of the underlying runtime are not the same thing. This issue usually appears when code opens a file with open(), inspects the returned descriptor, and expects identical semantics across operating systems, libc implementations, or compatibility layers.

Understanding the Root Cause

The core of this bug is a misunderstanding of what file access mode actually represents. When you call open(path, flags), the flags argument contains multiple categories of bits:

• Access mode bits: O_RDONLY, O_WRONLY, O_RDWR
• Status flags: O_APPEND, O_NONBLOCK, O_SYNC
• Creation flags: O_CREAT, O_TRUNC, O_EXCL

The important detail is that O_RDONLY is typically defined as 0. That means code like this is fragile:

if (flags == O_RDONLY) { ... }

It fails as soon as any other flag is combined with the open mode, and it can also mislead developers into thinking that a descriptor’s full flag value directly encodes readability in a simple equality check.

The correct way to inspect the access mode of an existing file descriptor is to call fcntl(fd, F_GETFL) and then mask the result with O_ACCMODE:

int mode = fcntl(fd, F_GETFL) & O_ACCMODE;

This matters because F_GETFL returns a composite flag set, not just the original access mode. Without masking, comparisons can produce false results. For example, a descriptor opened with read-only access plus append or nonblocking behavior will not compare equal to O_RDONLY if you inspect the raw value directly.

Another source of confusion is environment-specific behavior. Some runtimes or compatibility layers may normalize or emulate file descriptor behavior differently, especially when bridging POSIX APIs onto non-POSIX systems. In those cases, assumptions based on a single platform can break even when the code appears correct at first glance.

Step-by-Step Solution

Use a consistent, POSIX-safe pattern to detect whether a file descriptor is read-only, write-only, or read-write.

1. Open the file using the intended flags.
2. Call fcntl(fd, F_GETFL) to retrieve the descriptor status.
3. Mask the result with O_ACCMODE.
4. Compare against O_RDONLY, O_WRONLY, or O_RDWR.

Here is a reliable example:

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>

int get_fd_mode(int fd) {
    int flags = fcntl(fd, F_GETFL);
    if (flags == -1) {
        perror("fcntl(F_GETFL)");
        return -1;
    }

    return flags & O_ACCMODE;
}

const char *mode_to_string(int mode) {
    switch (mode) {
        case O_RDONLY:
            return "O_RDONLY";
        case O_WRONLY:
            return "O_WRONLY";
        case O_RDWR:
            return "O_RDWR";
        default:
            return "UNKNOWN";
    }
}

int main(void) {
    int fd = open("test.txt", O_RDONLY);
    if (fd == -1) {
        perror("open");
        return 1;
    }

    int mode = get_fd_mode(fd);
    if (mode == -1) {
        close(fd);
        return 1;
    }

    printf("Detected mode: %s\n", mode_to_string(mode));

    close(fd);
    return 0;
}

If your original code was doing direct comparisons on raw flags, refactor it like this:

int flags = fcntl(fd, F_GETFL);
if (flags == -1) {
    perror("fcntl");
    return -1;
}

switch (flags & O_ACCMODE) {
    case O_RDONLY:
        printf("read only\n");
        break;
    case O_WRONLY:
        printf("write only\n");
        break;
    case O_RDWR:
        printf("read write\n");
        break;
    default:
        printf("unknown mode\n");
        break;
}

If you need to validate behavior during debugging, print both the raw flags and the masked access mode:

int flags = fcntl(fd, F_GETFL);
printf("raw flags = %d\n", flags);
printf("access mode = %d\n", flags & O_ACCMODE);

This makes it much easier to see whether the discrepancy comes from extra status bits or a genuine runtime difference.

Common Edge Cases

• Checking raw flags directly: Comparing fcntl(fd, F_GETFL) to O_RDONLY or O_RDWR without masking is a common mistake.
• Assuming O_RDONLY is nonzero: Because O_RDONLY is usually 0, conditions like if (flags & O_RDONLY) do not work.
• Mixing open flags with descriptor state: Creation flags such as O_CREAT affect opening behavior, but they are not the same as the access mode you should inspect later.
• Using duplicated descriptors: After dup() or dup2(), the duplicated descriptor refers to the same open file description, so status flags can be shared in ways that surprise debugging.
• Platform compatibility layers: POSIX wrappers on non-native systems may return values that differ in layout or semantics from a Linux-only expectation. Always test with F_GETFL rather than relying on assumptions.
• Confusing file permissions with open mode: A file may have read and write permission bits on disk, yet a specific descriptor may still be opened read-only.

FAQ

Why does O_RDONLY often behave strangely in comparisons?

Because O_RDONLY is commonly defined as 0. That means bitwise tests such as flags & O_RDONLY will never tell you whether the descriptor is read-only. Use (flags & O_ACCMODE) == O_RDONLY instead.

Why not just store the original flags passed to open()?

You can, but it is less reliable when code paths become complex, descriptors are passed around, or flags are modified later. Querying the live descriptor with fcntl(fd, F_GETFL) gives you the current state.

Can a file descriptor be both readable and writable even if the file itself has different permissions?

The descriptor mode depends on how the file was opened and whether the open operation succeeded. The file’s on-disk permissions control whether that open was allowed, but once opened, the descriptor’s effective access mode is what you should inspect with O_ACCMODE.

The fix is simple but important: never infer descriptor access mode from raw flag equality or bit tests against O_RDONLY. Always retrieve the flags with fcntl and mask them using O_ACCMODE. That removes ambiguity and makes the behavior consistent across supported environments.