Bhuvan B created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5484
## Summary The RTEMS implementation of `rename()` does not comply with POSIX standards. When the target path already exists, `rename()` incorrectly fails instead of overwriting/replacing the existing target as required by POSIX. In `cpukit/libcsupport/src/_rename_r.c` ``` /* FIXME: This is not POSIX conform */ int new_eval_flags = RTEMS_FS_FOLLOW_HARD_LINK | RTEMS_FS_MAKE | RTEMS_FS_EXCLUSIVE; ``` This comment was added way back in 2012. Is this intential behavior still relevant? ## Steps to reproduce **Environment:** * BSP: `sparc/erc32` (sis simulator) 1. Start RTEMS shell in shell sample 2. Create initial directory structure: bash: ``` mkdir A mkdir B mv A B # Success: creates B/A ``` 3. Re-create directory A: bash: ``` mkdir A ``` 4. Attempt to move A into B again: bash ``` mv A B # FAILS with "rename A to B/A: File exists" ``` ``` touch a touch b SHLL [/] # mv a b # Should succeed, replacing b with a rename a to b: File exists SHLL [/] # mv a a # Should succeed as a no-op rename a to a: File exists ``` POSIX.1-2024: "If the _old_ argument and the _new_ argument resolve to either the same existing directory entry or different directory entries for the same existing file, _rename_() shall return successfully and perform no other action." **Expected result:**\ The second `mv A B` should succeed, overwriting/replacing the existing `B/A` directory according to POSIX compliance **Actual result:**\ `rename()` returns `error "rename A to B/A: File exists"` **Questions for maintainers:** 1. Is this non-compliant behavior intentional " 2. Are there security/safety reasons for preventing target overwriting? 3. Would patches to make `rename()` POSIX-compliant be accepted? 4. Do all `rename` implementations need to be updated if accepted? --- <!--Pre-set options - milestone--> -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5484 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
