编译C代码后可执行文件自动消失无报错，求助解决

咱们先拆解下你的问题：用gcc recover.c -o recover编译成功无报错，但生成的recover可执行文件很快消失，已经关闭杀毒软件但问题依旧。结合你提供的代码片段，我分几种情况给你排查思路：

一、先明确核心场景 #

先搞清楚是哪种情况：

• 如果是编译完刚生成文件就消失：重点排查系统权限、安全机制或编译环境问题
• 如果是运行可执行文件后才消失：大概率是程序崩溃触发了系统清理，或者代码逻辑有隐藏bug

二、编译完成后立刻消失的排查步骤 #

1. 查看编译的详细输出
   默认gcc只输出严重错误，试试用 verbose 模式编译，揪出可能隐藏的异常：

gcc -v recover.c -o recover

仔细看每一行输出，有没有类似“无法写入输出文件”的提示（哪怕是英文的）。

2. 检查当前目录的写入权限
   如果你在只读目录（比如系统默认目录、挂载的只读分区）编译，gcc可能看似成功，但实际没生成文件，或者生成后被系统自动清理。换个有写入权限的目录试试，比如你的用户家目录：

gcc recover.c -o ~/recover

之后去家目录（cd ~）看看recover文件是否存在。

3. 排查系统级安全工具
   除了普通杀毒软件，很多系统自带安全机制可能会拦截可执行文件：

• Windows：即使关了Defender，可能还有「受控文件夹访问」功能，去「Windows安全中心→病毒和威胁防护→管理设置→受控文件夹访问」看看是否开启，是否阻止了gcc生成文件。
• Linux：检查SELinux或AppArmor状态，比如用getenforce看SELinux是否处于Enforcing模式，临时关闭试试sudo setenforce 0，再编译看看效果。

三、运行后文件消失的排查步骤 #

如果是运行./recover后文件消失，重点看你的代码逻辑：
从你提供的代码片段来看，存在一个致命问题：初始状态下outptr未初始化。
当file_number == 0时，第一次遇到JPEG头（buffer[0] == 0xff等条件），因为file_number != 0不成立，不会进入if块打开第一个文件，此时outptr是野指针，执行fwrite(buffer, ..., outptr)会直接触发程序崩溃。

修复这个问题的思路：

// 先初始化outptr为NULL，避免野指针
FILE *outptr = NULL;
while(fread(buffer, sizeof(BYTE), 512, inptr) == 512) { 
    // 单独提取JPEG头检测逻辑，更清晰
    int is_jpeg_start = (buffer[0] == 0xff && buffer[1] == 0xd8 && buffer[2] == 0xff && (buffer[3] >= 0xe0 && buffer[3] <= 0xef));
    if (is_jpeg_start) {
        // 如果已经打开了文件，先关闭
        if (outptr != NULL) {
            fclose(outptr);
        }
        // 生成文件名并打开新文件
        get_file_name(file_number, file_name); 
        outptr = fopen(file_name, "w");
        file_number++;
    }
    // 只有当outptr有效时才写入，避免崩溃
    if (outptr != NULL) {
        fwrite(buffer, sizeof(BYTE), 512, outptr); 
    }
} 
// 最后记得关闭打开的文件，避免资源泄漏
if (outptr != NULL) {
    fclose(outptr);
}
fclose(inptr);

另外，程序崩溃后可以查看错误信息：

• Windows：在命令提示符运行recover.exe，看看有没有崩溃提示
• Linux：运行./recover，查看终端输出的错误，或者用dmesg查看内核日志，有没有程序崩溃的记录

四、其他小技巧 #

• 试试用touch test创建一个空文件，看看文件会不会消失，如果也消失，说明是目录或系统的问题，和编译无关
• 编译时不指定输出文件名，用默认的a.out（Linux）或a.exe（Windows），看看这个文件会不会消失，排除文件名的问题

内容的提问来源于stack exchange，提问作者Luís Otávio