Re: kern/49033: fs/vfs/t_vnops/udf_lookup_complex test case randomly fails

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/49033; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/49033: fs/vfs/t_vnops/udf_lookup_complex test case randomly fails
Date: Sat, 20 Aug 2016 22:20:47 +0700

 I believe the test is bogus.
 
 In this test case ...
 
          if (rump_sys_mkdir(pb, 0777) == -1)
                  atf_tc_fail_errno("mkdir");
          if (rump_sys_stat(pb, &sb1) == -1)  
                  atf_tc_fail_errno("stat 1");
 
          sprintf(pb, "%s/./dir/../././dir/.", mountpath);
          if (rump_sys_stat(pb, &sb2) == -1)  
                  atf_tc_fail_errno("stat 2");
 
          if (memcmp(&sb1, &sb2, sizeof(sb1)) != 0) {
                  printf("what\tsb1\t\tsb2\n");
 
 The second stat() (sb2) has to read "dir" (the ultimate subject of the
 stat) in order to resolve ".." and "." within it.
 
 Implememnations are permitted to update the access time of the directory
 due to that read of it.
 
 What posix actually says (section 4.8 "File Times Update") is ...
 
 [ 
 http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_08 
 ]
 
 As best I can tell, TC2 (due to be published sometime soon) has not
 altered any of this.
 
 The relevant paragraph is:
 
     Each function or utility in POSIX.1-2008 that reads or writes data
     (even if the data does not change) or performs an operation to change
     file status (even if the file status does not change) indicates which
     of the appropriate timestamps shall be marked for update.
 
 That part is boring (for our purpose here), and just says that sometimes
 one (or more) of the 3 required file times must be updated, and the std
 specifies which when that is required.
 
     If an implementation of such a function or utility marks for update
     one of these timestamps in a place or time not specified by POSIX.1-2008,
     this shall be documented,
 
 That says that the implementation can update the times when not actually
 required to do so, provided it documents that it does, but ...
 
     except that any changes caused by pathname resolution need not be
     documented.
 
 that is, it is explicitly allowed that pathname resolution itself might cause
 time updates - for that, the only rational time that would be updated is the
 access time, as nothing is ever being changed during pathname resolution - but
 both directories and symlinks do (when appropriate) get read as part of that
 process.   Nothing requires that the access times be updated, but nothing
 prohibits it either,
 
 That is, a test that assumes that the access time will not be altered is
 simply broken.
 
 That is what this particular test is doing.   It ought not be just marked
 as an expected failure, but either deleted, or at least fixed to ignore the
 access time (or if it is to test it at all, just verify it has not moved
 backwards in time.)
 
 I expect that the intermittent failures simply depend upon whether the
 mkdir() (which sets the access time originally - the first stat() does not
 need to read the directory, and so probably does not alter it - though
 technically it is permitted to) and the second stat() both happen to occur
 withing the same qemu clock tick - sometimes they obviously do, other times
 they clearly don't - inserting a sleep(1) would (I think) make the test
 fail reliably without that explicit "failed to fail" hack...
 
 If there is no objection, I will make appropriate changes to the test
 (in a few days.)
 
 kre