C++里用rename()重命名文件？别急，先看清它到底在干啥

刚写完一段C++代码，想把日志文件从log_temp.txt改成log_20241115.txt，顺手调了std::rename("log_temp.txt", "log_20241115.txt")——结果返回-1，errno是ENOENT。查了半天才发现：源文件根本没生成，不是函数坏了，是你还没写完就急着改名。

这就是rename()最常被误解的起点：它不负责“创建”，也不保证“存在”，它只做一件事——原子性地改变一个已有路径的名称或位置。理解这点，才能避开八成以上的坑。

rename()本质是POSIX系统调用的C封装，C++标准库（<cstdio>）里提供的版本，签名简单得让人放松警惕：

int rename(const char* old_name, const char* new_name);

但它背后的行为，和你想象中“点鼠标右键重命名”并不完全一样。

关键事实一：rename()能跨目录移动，但不能跨文件系统。
比如把/tmp/data.bin重命名为/home/user/archive/data.bin，只要两个路径属于同一挂载点（比如都是ext4根分区），就能成功；但如果/tmp是tmpfs内存盘，而/home在另一块SSD上，Linux会直接返回EXDEV错误。这时候你得老老实实读写拷贝+删除——rename()不会帮你降级处理，它只认“同设备”。

关键事实二：目标路径存在时，行为取决于平台。
POSIX规定：如果new_name已存在且是空目录，rename()会把它删掉再替换；如果是普通文件，则直接覆盖（Windows下默认不允许覆盖，除非用_CRT_SECURE_NO_WARNINGS并配合_rename变体）。但注意：覆盖不等于“安全更新”——没有原子写入保障，若进程崩溃在中间，可能留下截断或损坏的目标文件。真要安全替换，得用“写临时文件→rename()覆盖”的两步法，这也是SQLite、LevelDB等底层库的通用实践。

关键事实三：路径必须可访问，权限检查发生在调用时刻。
rename()需要对源路径所在目录和目标路径所在目录都有写权限（不是对文件本身！）。举个常见翻车现场：你在/var/log/myapp/下运行程序，想把./old.log移到../backup/old.log。如果../backup/目录权限是dr-xr-xr-x（无写权），哪怕old.log自己是644，rename()照样失败——因为移动操作实际修改的是父目录的dentry条目。

所以，写健壮的重命名逻辑，不能只看返回值，还得结合errno诊断：

#include <cstdio>
#include <cerrno>
#include <string>

bool safe_rename(const std::string& from, const std::string& to) {
    if (std::rename(from.c_str(), to.c_str()) == 0) return true;

    switch (errno) {
        case ENOENT:
            // 源文件不存在，或目标父目录不存在（比如to路径含未创建的子目录）
            break;
        case EACCES:
            // 权限不足：源/目标目录不可写，或文件被其他进程独占锁定（Windows常见）
            break;
        case EXDEV:
            // 跨设备移动，需fallback到拷贝+删除
            return copy_then_remove(from, to);
        default:
            // 其他情况如EBUSY（文件正被映射）、ENOTDIR（路径某段不是目录）等
            break;
    }
    return false;
}

这里有个容易被忽略的细节：rename()对符号链接的处理是“重命名链接本身”，而非链接指向的目标。如果你有ln -s /real/path target_link，执行rename("target_link", "new_link")，只是把软链接名字改了，/real/path完全不受影响。要操作目标文件，得先readlink()解析路径再调用。

另外，C++17引入了<filesystem>，提供了更现代的接口：

#include <filesystem>
namespace fs = std::filesystem;

try {
    fs::rename("old.txt", "new.txt"); // 抛异常，语义更清晰
} catch (const fs::filesystem_error& e) {
    // 可捕获具体错误类型，比如fs::exists()提前校验
}

但要注意：std::filesystem::rename底层仍调用系统rename()，并未解决跨设备问题，也未提供自动重试或权限修复。它只是把错误包装得更C++一点，该踩的坑一个不少。

最后说个真实场景：日志轮转。你想把app.log重命名为app.log.1，再把app.log.1变成app.log.2……这时千万别按顺序rename("app.log", "app.log.1") → rename("app.log.1", "app.log.2")。如果第一步成功、第二步失败，app.log.1就丢了。正确做法是逆序操作：先rename("app.log.1", "app.log.2")，再rename("app.log", "app.log.1")——这样即使中断，最多丢失一次旧日志，不会破坏整个链。

rename()不是魔法棒，它是把双刃剑：轻量、原子、高效，但也要求你对文件系统有基本敬畏。写代码时多看一眼errno，比查十遍文档都管用。毕竟，硬盘不会抱怨，它只会默默返回-1。