Xref: utzoo comp.sys.apollo:6149 comp.lang.perl:2104
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!carlton
From: carlton@apollo.HP.COM (Carlton B. Hommel)
Newsgroups: comp.sys.apollo,comp.lang.perl
Subject: Re: perl failed on regression test, pl 27 - explaination
Keywords: perl, op.stat
Message-ID: <4c346f83.20b6d@apollo.HP.COM>
Date: 15 Aug 90 01:53:00 GMT
References: <1756@tuvie>
Sender: root@apollo.HP.COM
Reply-To: carlton@apollo.hp.com
Organization: Apollo Computer, Chelmsford, MA
Lines: 33

mike@tuvie (Inst.f.Techn.Informatik) describes how the latest patchlevel
for perl fails the following regression test:
    ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,
	$blksize,$blocks) = stat('Op.stat.tmp');
    if ($mtime && $mtime != $ctime) {print "ok 4\n";} else {print "not ok 4\n";}

I saw this when I compiled patchlevel 18.  I submitted it as a defect, and
the following discussion ensued:

Date	  engineer	baselevel	
02/03/90  carlton     sr10.3bl45
stat mtime & ctime different for newly created file
 [Yes.  We don't try to keep the .ctime == .mtime for a newly 
  created file.  (the .mtime is assigned when the file is 
  created; the .ctime is advanced "just" afterwards as various 
  attributes are being assigned: protection info, type, etc.) 
  Do any of the SVID, POSIX or X/OPEN actually stipulate this? ]
 [I haven't seen anything in any of the standards that mandate
  this behavior. Carlton, is this important for some application? ] 
 [No, it isn't. -carlton ]
 [Nobody promises that they will be the same. ] 

To summarize, yes, perl on Domain/OS will occasionally fail this test,
but no, it isn't an indication that anything is wrong with either perl or
Domain/OS.

If it turns out that, indeed, mtime == ctime is mandated, please email me
the citation for the appropriate standards document, and I will reopen
the bug.

Carl Hommel
carlton@apollo.hp.com
"I could write a perl script to do that...."