RTEMS | rename() fails when target exists - violates POSIX complience (#5484)

[Bhuvan B (@BhuvanB404)]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260210/47f8e4bf/attachment-0001.htm>