fstests/fstime errors

[Chris Johns]

Sebastian Huber wrote:
> On 2013-07-28 06:46, Chris Johns wrote:
>>> WARNING - log/mrfs_fstime did not appear to complete execution
>>
>> This one is a little more interesting. The test is correct and the RFS
>> fails however it passes this ...
>>
>> f = open (file03, O_CREAT | O_WRONLY);
>> close (f);
>> sleep (for_a_few_seconds);
>> f = open (file03, O_TRUNC | O_WRONLY);
>> close (f);
>>
>> RTEMS implements the truncate in the open call for the file system
>> with an ftruncate call. In this case the file system follows the
>> truncate call's requirements of not updating the mtime and ctime
>> fields, however open states ..
>
> For ftruncate we have this:
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/ftruncate.html
>
> "Upon successful completion, if /fildes/ refers to a regular file, the
> /ftruncate/() function shall mark for update the /st_ctime/ and
> /st_mtime/ fields of the file and the S_ISUID and S_ISGID bits of the
> file mode may be cleared. If the /ftruncate/() function is unsuccessful,
> the file is unaffected."
>
> [...]
>
> "The following new requirements on POSIX implementations derive from
> alignment with the Single UNIX Specification:
>
> *
>
> The DESCRIPTION is changed to indicate that if the file size is
> changed, and if the file is a regular file, the S_ISUID and S_ISGID
> bits in the file mode may be cleared."
>

<sigh> ... and to add a third factor the truncate call states ...

  "The truncate() function shall not modify the file offset for
   any open file descriptions associated with the file. Upon
   successful completion, if the file size is changed, truncate()
   shall mark for update the last data modification and last file
   status change timestamps of the file, and the S_ISUID and S_ISGID
   bits of the file mode may be cleared."

This is the basis for the file01 test we have.

>>
>> "If O_TRUNC is set and the file did previously exist, upon
>> successful completion, open() shall mark for update the last
>> data modification and last file status change timestamps of
>> the file."
>>
>> I assume the open's requirements override the truncate's requirements
>> here. I will fix the RFS to follow the truncate requirements and add
>> this test to the test suite. I suspect the fix for this requires the
>> truncate op handler needing a parameter to say how to handle the time
>> fields.
>
> If I read this correctly, then the O_TRUNC and ftruncate() are similar
> with respect to the mtime and ctime update. What is unclear is if this
> should only happen if the file size changes.

I see open as being specific and the opposite of truncate and ftruncate 
is not clear. It is interesting that FreeBSD and Linux do not follow 
what POSIX says.

The issue for RTEMS is truncate follows ftruncate because it is 
implemented in the libcsupport layer as open, ftruncate. Open uses 
ftruncate as O_TRUNC is implemented as open, ftruncate yet they have to 
different requirements.

Another point is this test fails on FreeBSD and Linux ...

   /*
    * file01 shall not update
    */
   status = stat (file01, &statbuf);
   rtems_test_assert (status == 0);
   ctime2 = statbuf.st_ctime;
   mtime2 = statbuf.st_mtime;

   rtems_test_assert (TIME_EQUAL (ctime1, mtime2));

>
> Regarding the atime I would not support this. See also
>
> http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime
>

The RFS supports atime and it does it efficiently. The file handle 
allocates the inode fields in a shared structure that all open handles 
to a file share. Only when all handles are closed or a sync call is made 
is this data flush to the media. Technically reading a file does not 
update the file, only the metadata related to the file is updated. 
Mounting a filesystem to read a file also results in metadata in the 
filesystem being updated, ie superblock flags to indicate the file 
system is mounted.

The people involved in this discussion should lobby POSIX for a change 
backed up with real data showing the impact in real systems. Once 
changed I will look at it otherwise I see posts like that as noise.

Chris