The testcase failed because the rmdir call in that case had two possibilities to fail and the implementation of rmdir checked the other possibility first.
Closes#5071
This file is ancient and there have been many, many contributors to RTEMS that
deserve equal acknowledgement.
I have opened an issue to create a new contributrors section in the
documentation in the docs projects:
* rtems/docs/rtems-docs#21
I have linked this version of the file there but this file should not ship with
the next version of RTEMS given the GitLab migration it will not be converted to
MarkDown
This file is now obsolete now that we have moved to GitLab. A ticket has been
opened in rtems/docs/rtems-docs#21 to discuss adding a contributors section.
GitLab lists who the 'Code Owners' are on top of every file in the web source
browser this is the canonical way to find out who maintainers are of those files
or directories.
Even with knowing who the maintainers are the best way to figure out who is
looking after what is to open an issue or an MR. This way we can keep a group
level of maintainership over the code base and have CODEOWNERS enforce approvals
before merging.
All this does is points to the README. The README points to the docs website as
it should.
INSTALL files are falling out of favour since sites show README.* by default
over an INSTALL file.
This file has not been relevant in at least 8 years and even then only for
texinfo? The file calls itself Experimental and relies on CVS. It was used for
cutting old RTEMS releases.
Merge all licenses into one large file with a TOC. This way we can link to one
file and not have to worry about having many files everywhere.
The original licenses have been copied in without modification though it will
render differently online.
Changed fstest support to allow control on the test result of each fstest, updated all fstest accordingly.
Modified FS_FAIL macro to fail hard and not just print a message which rtems-test runner ignores.
Split failing test cases from the ones that passes; added fsrenameexisting, fsrenamepermexisting, fsrmdirparent, fsrenamelongname and fsrenamemaxlinks test cases.
Marked fsrenameexisting, fsrenamepermexisting as expected to fail due to #2169.
Marked fsrmdirparent as expected to fail, covered by #5071.
Marked fssymlink as expected to fail due to rename problems partially covered by #2169.
Marked rfsfsrenamelongname as expected to fail, covered by #5069.
Marked *fsrenamemaxlinks as expected to fail, covered by #5070.
Marked jffs2fsrenamelongname and jffs2nandfsrenamelongname as expected to fail, as JFFS2 seems to not have a limit on the file name, covered by #5073
rename now actively changes the inode of the file being renamed.
This change has been done to fix an issue when the file being renamed is already opened before the rename, in particular failing to update the inode number (and the two lookup tables) could cause at least two problems:
1) A new file created in the same source folder of the file being renamed may get the same fat file descriptor of the renamed file
2) An open to the renamed file opens a new fat file descriptor, thus putting out of sync the operations on the file (two distinct fat file descriptor working on the same clusters and entries)
Previously the inode was in any case changed once the file was closed.
Another possible solution would have been to separate the inode number from the lookup table, but this solution would have required much more memory because it needed to keep track of all files seen in the file system up to the last operation and not only the opened ones.
Closes#5044
