gonzalez@VAX.BBN.COM (06/15/87)
In attempting to port a package to Masscomp Unix (aka RTU), I discovered a filesystem difference between BSD and RTU. Under RTU, if you attempt a read of a file that is zero size, the access time is *not* updated. Under BSD, it is. I infer from this that BSD counts open(2) calls, while RTU counts successful read(2) operations. Since RTU is largely derived from AT&T, I've wondered whether this is the case under SysV, or if this behavior is limited to Masscomp systems. If the latter is true, perhaps the difference should be viewed as a bug in RTU? -Jim Gonzalez BBN Labs, Inc. gonzalez@vax.bbn.com
guy@gorodish.UUCP (06/16/87)
> In attempting to port a package to Masscomp Unix (aka RTU), I discovered > a filesystem difference between BSD and RTU. Under RTU, if you attempt > a read of a file that is zero size, the access time is *not* updated. > Under BSD, it is. I infer from this that BSD counts open(2) calls, > while RTU counts successful read(2) operations. You infer incorrectly. No UNIX system I know of changes the access time on "open" calls. The difference is just in what is a "successful" read operation. 4BSD considers a "read" to be successful even if it moves no data; RTU, presumably, does not. > Since RTU is largely derived from AT&T, I've wondered whether this is > the case under SysV, or if this behavior is limited to Masscomp systems. More correctly, "Since RTU is largely derived from System V..."; there are versions of AT&T UNIX that exhibit both behaviors. Based on the source lying around here, here is the behavior of various systems on "read"s on plain files that return a byte count of 0: V7: access time updated (note that this *is* AT&T UNIX, so it's not a question of "AT&T vs. BSD") 4.[23]BSD: access time updated S5: access time not updated In other words, somewhere between V7 and S5, the behavior of UNIX was changed. The IACC flag, indicating that the access time should be updated, used to be updated at the beginning of "rdwri"; in S5, it is updated (more-or-less) every time data is moved. 4BSD was originally based on UNIX/32V, which probably had code very similar to, if not the same as, V7's. The V7 behavior was retained in the 4.2BSD "rwip". The SVID says that "st_atime" is "the time when file-data was last accessed". One can probably argue this either way; my inclination is to consider the S5 behavior to be closer to what is specified here than the V7 behavior, given that if the file contains no data it is impossible to access its data. Does the package in question depend on the V7-style behavior in such a way that it would be hard to change the package to work with the S5-style behavior or that the version of the package that does not depend on this behavior would be considered noticeably inferior? If so, this might be an argument against the S5 behavior; if not, the package should be changed not to depend on this behavior. (Note that under S5 you can set both the accessed and modified times of a file to the present, if you own the file or have write permission on it, by using "utime" with a null pointer as its second argument.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/16/87)
In article <21145@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
-One can probably argue this either way; my inclination is
-to consider the S5 behavior to be closer to what is specified here
-than the V7 behavior, given that if the file contains no data it is
-impossible to access its data.
To me, it seems trivial to access all its data!
This is the old "zero-sized object" issue.