RTEMS | msdos: update inode during rename (!80)

[Loris Nardo (@loris.nardo)]

Loris Nardo commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/80#note_108804


I've checked the reason why the tests failed on the "null" group, here is the list:
- jffs2fsrenamelongname and jffs2nandfsrenamelongname fails because the rename succeed
- rfsfsrenamelongname fails because the limit on the name is mostly related to the block size and in the case of the test the block size is twice the `NAME_MAX`, however when testing with a filename longer than the block size then the operation fails after having allocated all the blocks to try to find a suitable empty directory (which will never happen) with `ENOSPC`
- *fsrenamemaxlinks I'm not quite sure if the test is valid, it makes an assumption that every file in a directory holds a reference to the folder itself and this counts toward the `LINK_MAX` value.
- mdosfsfsrenamemaxlinks fails because `LINK_MAX` is set to 5, but FAT cannot have links to files and the number of files a directory can hold depends on how many entries have been used for long file names (rename succeed)
- jffs2fsrenamemaxlinks and jffs2nandfsrenamemaxlinks fails because rename succeed
- mimfsfsrenamemaxlinks fails because rename succeed, `LINK_MAX` applies only to linked files and not to the parent directory
- mrfsfsrenamemaxlinks fails because rename succeed

Moreover for the *fsrenamemaxlinks I've only found `IMFS_link` that sets the errno to `EMLINK`.  
I can add this explaination to the `set-test-state`

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/80#note_108804
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/20240707/28eac53b/attachment.htm>