[PATCH] New fstest to check rename POSIX conformance

[Andre Marques]

On 02/19/14 14:00, Sebastian Huber wrote:
> 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.

Skipping for now.

>
>>
>>>
>>>>
>>>> - 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.
>

So I leave EROFS out of this test?

> 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

Yes I'm using support files on Makefile.am.

For mount() should I use a ramdisk for the device file?

I tried to create a ramdisk as in

http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__rtems__ramdisk.html#gac6c99eed9f3b92bb4cf5184b25972e65

but the program exits during the rtems_blkdev_create() call, if I use 
"/dev/rda" as the device path.

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

I'm reading this as mounting an instance of the system filesystem. Am I 
right?

>>
>> 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
>> [...]
>
>