Fuse文件系统未调用release函数问题咨询

我之前也踩过类似的坑，结合Fuse的实际工作逻辑，咱们一步步拆解可能的原因和排查方案：

1. 先确认release回调的注册是否到位 #

首先检查你的fuse_operations结构体初始化，一定要确保release字段正确指向了my_release函数，别漏写或者写错函数名：

static struct fuse_operations fops = {
    .open = my_open,
    .release = my_release, // 这里必须明确赋值，不能省略
    // 其他回调函数...
};

这是最容易疏忽的点——如果这里没把release回调挂进去，Fuse根本不知道要调用你的my_release。

2. 搞清楚Fuse中close和release的触发逻辑 #

别被字面意思误导：Fuse的release并不是每次用户调用close()系统调用就会触发。因为操作系统会对文件描述符做引用计数：

• 如果同一个文件被多次open，只有当最后一个引用的文件描述符被close时，release才会被调用
• 如果进程异常崩溃或强制退出，可能不会走正常的close流程，但Fuse通常会在进程退出后自动清理资源，不过这时候release是否触发要看具体的Fuse版本和挂载参数

你可以做个简单测试：连续几次open你的/example文件，然后逐个close，看最后一次close时是否会打印RELEASED日志。

3. 检查my_open中fh的设置是否正确 #

你的my_release里用到了fi->fh，那得确保my_open里正确初始化了这个字段，比如：

static int my_open(const char *path, struct fuse_file_info *fi) {
    if (!strcmp(path, "/example")) {
        // 分配缓冲区并把指针转成uint64_t赋值给fh
        void *buf = malloc(1024);
        if (!buf) return -ENOMEM;
        fi->fh = (uint64_t)buf;
    }
    // 其他逻辑...
    return 0;
}

虽然fh的错误不会直接导致release不触发，但如果fh没正确设置，后续的清理逻辑会出问题，先把基础工作做扎实。

4. 排查挂载参数是否影响回调触发 #

有些Fuse挂载参数可能会间接影响回调行为，比如direct_io、kernel_cache这类参数。你可以尝试不带任何额外参数重新挂载文件系统，测试release是否能正常触发，排除参数干扰的可能。

5. 验证日志输出是否正常 #

先确认你的LOGGING宏能正常工作——比如在my_open里也加一条日志，看看open操作的日志能不能正常输出。有时候可能是日志被重定向、缓冲区没刷新，导致你误以为release没触发，实际它已经被调用了。

给你一个简单的测试程序，用来验证：

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

int main() {
    int fd = open("/mnt/your_fuse_mount/example", O_RDONLY);
    if (fd < 0) {
        perror("open failed");
        return 1;
    }
    printf("File opened, closing now...\n");
    close(fd);
    printf("File closed\n");
    return 0;
}

编译运行这个程序，然后检查你的日志是否出现RELEASED的输出。

如果以上步骤都试过还是没解决，建议检查一下你使用的Fuse版本——Fuse 2.x和3.x在回调触发逻辑上有一些细微差异，可能是版本兼容性问题导致的。

内容的提问来源于stack exchange，提问作者Aneesh Durg