[PATCH] New fstest to check rename POSIX conformance

[Sebastian Huber]

On 2014-02-19 11:27, Andre Marques wrote:
> Sorry for the delay.
>
> I'm almost ready to send the patch with the test, but there are some questions.

This is nice.

>
> On 02/10/14 08:14, Sebastian Huber wrote:
>> Hello Andre,
>>
>> thanks for the test case.
>>
>> On 2014-02-08 13:26, Andre Marques wrote:
>>> Hi,
>>>
>>> As discussed in [1], I created a new fstest to check the rename()
>>> implementation against the POSIX specification [2].
>>>
>>> What the attached patch does not test:
>>>
>>> - Testing the existance of a link visible to other processes during the rename
>>> process (ensuring that there is always a reference to the file). Not sure about
>>> the best way to test this.
>>
>> The file system instance is locked during the rename operation, so other
>> threads cannot interfere here.
>>
>
> Should I test the lock then?

I think a test would be quite difficult.  I would postpone this.

>
>> What happens if you rename a file with an open file descriptor should be tested.
>
> That is already covered on the test.
>
>>
>>>
>>> - Testing that after all processes close their references to a file after it
>>> was removed by rename() the file contents are removed (or marked as free space,
>>> I guess). I only found platform dependent ways of dealing with disk block's.
>>
>> Maybe you can use the statvfs() function for this.
>
> The statvfs() function gives "not implemented" on the IMFS filesystem, so I
> changed the used filesystem to MOUNTED RFS.

Ok, maybe we should implement this function for the IMFS or skip the test case 
if statvfs() is not available.

>
>>
>>>
>>> - Testing errno values in error situations. There is already a fstest named
>>> fserror which purpose seems to be checking errno values for a bunch of
>>> functions (rename included, but with some errno values missing). Not sure if I
>>> should put them in this test or add to fserror.
>>
>> I would move all rename related tests to this new test program.
>
> About the errno value testing, I'm currently missing EIO, ENOSPC, EROFS and EXDEV.
>
> EROFS and EXDEV require mounting a second filesystem. How can I do this in
> RTEMS? Can it be done at runtime? I've been looking at the fileio sample, which
> uses the fsmount() function, but I need a disk to mount with it.

For EROFS there is already a test in fstests/fsrofs01.

You can mount as many file system instances as you want.  You can do this with 
mount().  The mount() parameters are file system dependent.  The generic file 
system tests (and your rename test should be one of them) use a support file 
for this:

./testsuites/fstests/mrfs_support/fs_support.c
./testsuites/fstests/mimfs_support/fs_support.c
./testsuites/fstests/mdosfs_support/fs_support.c
./testsuites/fstests/imfs_support/fs_support.c
./testsuites/fstests/jffs2_support/fs_support.c

You can use the system file system as the second file system for the EXDEV test.

>
> For ENOSPC I'm thinking in mounting a small disk and testing that way, but for
> EIO I don't know how to simulate a physical error. How can I generate an I/O
> error?

Generating an IO error will be difficult or impossible (e.g. for IMFS).  For 
the disk device based file systems you need a special driver.  I would ignore 
this for now.

>
>>
>>>
>>>
>>> This test uses the MOUNTED IMFS filesystem, for no particular reason, so if
>>> that's an issue please let me know.
>>>
>>> [1] - http://www.rtems.org/pipermail/rtems-users/2014-January/012378.html
>>>
>>> [2] - http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html
>>>
>>> --André Marques
> [...]


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.