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
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
