Path: utzoo!utgpu!watserv1!tom
From: tom@mims-iri (Tom Haapanen)
Newsgroups: comp.mail.mush
Subject: Re: Locking in 7.0 (was: Help, please)
Message-ID: <1477@watserv1.waterloo.edu>
Date: 15 Mar 90 03:34:43 GMT
References: <1365@watserv1.waterloo.edu> <7821@ogicse.ogi.edu> <1383@watserv1.waterloo.edu> <1389@watserv1.waterloo.edu> <7864@ogicse.ogi.edu>
Sender: daemon@watserv1.waterloo.edu
Organization: University of Waterloo, WATMIMS Research Group
Lines: 24

Barton E. Schaefer <schaefer@ogicse.ogi.edu> writes:
> } I think I've narrowed this down to lock.c and the SysV file locking: it 
> } appears that Mush sets the modify time but not the access time on the
> } file.
>
> Sigh.  This is all the result of some discussion about race conditions
> that came by back before 7.0 was released.  [...]
> At the time of that discussion, it was asserted that the modify time of
> the file would *not* be changed by closing the file descriptor *if* a
> fflush() was performed (which it is).  Apparently, though, some systems DO
> change the modify time when that descriptor is closed, even though nothing
> more has been written, causing the bogus "You have new mail." messages.

I would like to hereby absolve Barton, Dan and Mush of any and all blame
for this.  Of course SGI tech support was quite unaware of what fflush()
followed by fclose() should do, but SGI has now admitted that this is a
bug in IRIX 3.2, and will be fixed in a future release.  So I guess I'll
just hack it (for now) to reopen the file for read and call utime() again.

And I'll finally get Mush 7.0 -- yea!

[ \tom haapanen -- university of waterloo -- tom@mims-iris.waterloo.edu    ]
[ "i say what i say, but i say it for myself and myself only" -- me        ]
[ "i don't even know what street canada is on"                -- al capone ]