tom@mims-iri (Tom Haapanen) (03/10/90)
Tom Haapanen <tom@mims-iri> writes: >One question first, >though: now, when I quit from my mailbox, csh tells me every time that >I have new mail (when I don't). What's causing this? 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. Before I immerse myself in this, does anyone have Mush running nicely on real System V? If so, could you let me know what you did with lock.c? Or whether I should be calling SGI tech support... [ \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 ]
schaefer@ogicse.ogi.edu (Barton E. Schaefer) (03/10/90)
In article <1389@watserv1.waterloo.edu> tom@mims-iri (Tom Haapanen) writes: } Tom Haapanen <tom@mims-iri> writes: } >One question first, } >though: now, when I quit from my mailbox, csh tells me every time that } >I have new mail (when I don't). What's causing this? } } 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. Before I immerse myself in this, does anyone have Mush running } nicely on real System V? If so, could you let me know what you did with } lock.c? Or whether I should be calling SGI tech support... Sigh. This is all the result of some discussion about race conditions that came by back before 7.0 was released. Mush DOES set both the access and modify times of the file, but it does so *before* releasing the lock it holds on the file. This is to prevent it from "hiding" the arrival of new mail -- theoretically, new mail could arrive between the time mush releases its lock and the time mush resets the modify time, and thus the new mail would never be seen by the shell. 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. So the question is, would you rather have the csh NOT tell you when new mail HAS arrived, or have it tell you mail has arrived when none did? It probably *is* a system bug that closing a file changes its modify time, so yes, you probably should call SGI. But it may also be an NFS problem, in that the fflush() done before the utimes() may not actually propagate to the NFS filesystem until after the close(). Under those circumstances, anything mush could do would sometimes be wrong, and the decision becomes whether to do the thing that is right most often or the thing that it is most important to get right. And, of course, it depends on which one you think is most important; the earlier vote seemed to indicate that it was very distressing to have the shell fail to tell you about new mail, but only annoying to have it tell you there was mail when there really was not. The disadvantage I'm now seeing is that if the shell is routinely wrong about new mail, won't you start ignoring it and thereby fail to see the *real* new mail anyway? -- Bart Schaefer "EARTH: Surrender IMMEDIATELY or we PICKLE DAN QUAYLE" "THPPFT!" schaefer@cse.ogi.edu (used to be cse.ogc.edu)
tom@mims-iri (Tom Haapanen) (03/15/90)
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 ]