fd_datasync failure. - Githubissues

Userzxcvbvnm commented 2 weeks ago

Subject of the issue

fd_datasync fails. I'm not sure whether this is a bug.

Test case


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

int get_fd(const char *filename, int flags) {
    int fd = open(filename, flags);

    if (fd == -1) {
        printf("Get file descriptor of file %s failed!\n", filename);
        return -1;
    } else {
        printf("Get file descriptor of file %s succeed!\n", filename);
        return fd;
    }
}

void closebyfd(int fd) {
    if (close(fd) == -1) {
        printf("Close the file %d by descriptor failed!\n", fd);
    }
}

void fd_datasync_00001_TKDa3(int fd) {
    printf("Enter function fd_datasync_00001_TKDa3\n");

    if (fdatasync(fd) == -1) {
        printf("Failed to synchronize data to disk\n");
        return;
    }

    printf("Data synchronized to disk successfully\n");
}

int main() {
    int fd = get_fd("subdir_1/subfile_2", O_RDONLY);
    if (fd == -1) {
        return 1;
    }

    fd_datasync_00001_TKDa3(fd);

    closebyfd(fd);

    return 0;
}

Your environment

Ubuntu 20.04 x86_64 WAMR 1.3.2

Steps to reproduce

Steps to reproduce: (1)compile to wasm:./wasi-sdk-21.0/bin/clang --target=wasm32-unkown-wasi --sysroot=./wasi-sdk-21.0/share/wasi-sysroot test.c -o test.wasm

(2)Running wasm: (Before run the Wasm file, subdir_1/subfile_2 exists.) iwasm --dir=. test.wasm

Expected behavior

Get file descriptor of file subdir_1/subfile_2 succeed!
Enter function fd_datasync_00001_TKDa3
Data synchronized to disk successfully

This is what wasmtime and WasmEdge do.

Actual behavior

Get file descriptor of file subdir_1/subfile_2 succeed!
Enter function fd_datasync_00001_TKDa3
Failed to synchronize data to disk

TianlongLiang commented 1 week ago

Technically, this is not a bug. If we take a look at the system call manual for fdatasync: https://linux.die.net/man/2/fdatasync it states that On some UNIX systems (but not Linux), fd must be a writable file descriptor. WAMR's implementation chosed a rather strict limitation to ensure consistent behavior across different platforms. So if you change the O_RDONLY to O_RDWR or O_WRONLY, everything will be fine

yamt commented 1 week ago

wasi-libc doesn't request DATASYNC rights for O_RDONLY. https://github.com/WebAssembly/wasi-libc/blob/320bbbcced68ce8e564b0dc4c8f80a5a5ad21a9c/libc-bottom-half/cloudlibc/src/libc/fcntl/openat.c#L27-L42