mirror of
https://github.com/espressif/esp-idf.git
synced 2026-09-22 13:01:16 +03:00
4262553c56
POSIX rename() silently replaces the destination when it already exists, while FatFs' f_rename() refuses with FR_EXIST. rename() on a FAT mount therefore fails with EEXIST where the same call succeeds on other file systems, and every caller that wants portable behaviour has to remove the destination itself. Add CONFIG_FATFS_VFS_RENAME_REPLACES_DESTINATION (default n, so existing behaviour is unchanged) to emulate the POSIX semantics: when f_rename() reports FR_EXIST, remove the destination and retry, all under the lock already held for the rename so no other VFS caller observes the gap. The POSIX rules on what may replace what are applied before anything is removed, because f_unlink() deletes empty directories as readily as files and would otherwise discard a directory to make way for a file: renaming a file onto a directory fails with EISDIR, a directory onto a file with ENOTDIR, and a directory onto a non-empty directory with ENOTEMPTY. Without the option all of these keep failing with EEXIST. Moving a directory into its own subtree is rejected with EINVAL as well. f_rename() does not check for this and links the directory into its own tree, losing its contents, so this is a correctness fix rather than a matter of which error is reported. Renaming an entry to itself needs no special handling: f_rename() reports FR_EXIST only when the destination resolves to a different directory entry, so a self-rename, including one written with a different spelling of the same name, already succeeds. The emulation cannot be atomic, nor can it honour the POSIX guarantee that a failed rename leaves an instance of the destination in place: FAT cannot replace a directory entry in one step, so an interruption between removing the destination and completing the rename can leave neither name. This is documented in the option's help text.
2 lines
47 B
Plaintext
2 lines
47 B
Plaintext
CONFIG_FATFS_VFS_RENAME_REPLACES_DESTINATION=y
|