becker@CS.ROCHESTER.EDU (09/22/87)
I'm working on X11 on a Sun 3 OS3.4. Xmh dies (killing Xsun too) when I try to reply to a message. It dies in utime(). The line is ~453 in tocutil.c -- it looks like (void) utime(toc->scanfile, (time_t *)NULL); The problem (I think) is that utime() on SunOS3.4 gives a segmentation violation when given this (dereferencing the NULL no doubt...). What's the intent of this code -- to give the file a *very* old time stamp? Also, I use a draft folder with MH (set in mh .mh_profile). Looks like xmh has problems with this in a couple of places. Seems better now that I commented the entry out of my .mh_profile. (I'd be glad to supply details on this if anyone cares). Tim Becker. becker@cs.rochester.edu
weissman@decwrl (09/23/87)
According to man utime (on an Ultrix 2.0 system), if the second argument to utime is a NULL, then the access and modification times of the file are set to the current time. Sounds like a bug in Sun's utime... - Terry Weissman weissman@decwrl.dec.com ...!decwrl!weissman
becker@CS.ROCHESTER.EDU (09/23/87)
According to man utime (on an Ultrix 2.0 system), if the second argument to utime is a NULL, then the access and modification times of the file are set to the current time. Sounds like a bug in Sun's utime... Terry, We run 4.2bsd, 4.3bsd, and SunOS Unix machines here. None of the man pages for utime() list the NULL argument feature. Looks like it's only in Ultrix (possibly others?). I'm glad you replied (as the author of xmh, right?) -- with this info in mind (not in Sun or 4.3bsd), perhaps you could consider changing the code in view of better portability. Thanks for your consideration! Tim Becker. becker@cs.rochester.edu PS. I love the *speed* of xmh. I do have some problems with it still, but it looks wonderful. Thanks!
guy%gorodish@Sun.COM (Guy Harris) (09/23/87)
> According to man utime (on an Ultrix 2.0 system), if the second > argument to utime is a NULL, then the access and modification times of > the file are set to the current time. Sounds like a bug in Sun's utime... According to "man utime" (on a SunOS 3.x system): The "utime" call uses the `accessed' and `updated' times in that order from the "timep" vector to set the corresponding recorded times for "file". which says nothing whatsoever about a null pointer as the second argument. Sounds like a deficiency in your notion of what a "bug" is, or a deficiency in your notion of which manuals to check for descriptions of the behavior of SunOS (in case you weren't aware of it, the Ultrix documentation does *not* specify what SunOS does!).... The "null pointer as second argument" feature is a System V-ism. It is available - to a *limited* degree - in 3.2 and later releases; however, since the underlying system call ("utimes") does not support this notion, it can only change the times to the current time if you own the file. This will be changed in a future release to support a NULL second argument both to "utimes" and "utime"; the effect will be that, *to the best of the ability of all systems involved*, the accessed and modified times will be set to the current time. You must have write permission on the file or be the owner to do this; furthermore, if the file is being accessed over NFS, the file system code on the server must be willing to let you do this. (It's done by a special hack on top of the current NFS protocol, so most servers will probably *not* be willing to do so....) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
jlm@comvme.UUCP (Jeff Morris) (09/23/87)
In article <8709222129.AA00357@wasat.cs.rochester.edu> becker@CS.ROCHESTER.EDU writes: > > According to man utime (on an Ultrix 2.0 system), if the second > argument to utime is a NULL, then the access and modification times of > the file are set to the current time. Sounds like a bug in Sun's utime... > >Terry, > >We run 4.2bsd, 4.3bsd, and SunOS Unix machines here. None of the man pages for >utime() list the NULL argument feature. Looks like it's only in Ultrix (possibly >others?). I'm glad you replied (as the author of xmh, right?) -- with this info >in mind (not in Sun or 4.3bsd), perhaps you could consider changing the code >in view of better portability. > >Thanks for your consideration! > >Tim Becker. >becker@cs.rochester.edu > >PS. I love the *speed* of xmh. I do have some problems with it still, but it >looks wonderful. Thanks! Newsgroups: comp.windows.x Subject: Re: xmh and utime() Summary: System V Expires: References: <8709222111.AA16569@gilroy.dec.com> <8709222129.AA00357@wasat.cs.rochester.edu> Sender: Reply-To: jlm@comvme.UUCP (Jeff Morris) Followup-To: Distribution: world Organization: Motorola Microcomputer Division, Tempe, Az. Keywords: .In article <8709222129.AA00357@wasat.cs.rochester.edu> becker@CS.ROCHESTER.EDU writes: .> .> According to man utime (on an Ultrix 2.0 system), if the second .> argument to utime is a NULL, then the access and modification times of .> the file are set to the current time. Sounds like a bug in Sun's utime... .> .>Terry, .> .>We run 4.2bsd, 4.3bsd, and SunOS Unix machines here. None of the man pages for .>utime() list the NULL argument feature. Looks like it's only in Ultrix (possibly .>others?). I'm glad you replied (as the author of xmh, right?) -- with this info ... .> .>Tim Becker. .>becker@cs.rochester.edu According to the man page for utime(2), System V, a NULL parm for times means use the current time, just as with Ultrix, above. My manual for SYSTEM V/68 (R3V3) mentions the same thing.
bob@wiley.UUCP (09/24/87)
According to man utime (on a Sun 3.4 system), no mention is made about the possibility of a NULL second argument. So I decided to look at the sources. What do you know; utime uses the second argument without checking for it being NULL. I don't know which system is right, but it would be nice if we could have an official patch for this problem. -- ---Bob Amstadt bob@wiley.uucp {csvax.caltech.edu,trwrb.uucp}!wiley!bob
bilbo.geoff@CS.UCLA.EDU.UUCP (09/25/87)
> According to the man page for utime(2), System V, a NULL parm for times > means use the current time, just as with Ultrix, above. > My manual for SYSTEM V/68 (R3V3) mentions the same thing. The proper manual for looking up this sort of thing is neither SV, Ultrix, nor BSD, but rather V7. If you don't write for the lowest common denominator, you can expect troubles. (And yes, I'm aware that V7 isn't really a perfectly common denominator either, but at least it's close.) A perfect example of this is the common penchant for using setitimer, even when alarms would do just as well. Geoff Kuenning geoff@lcc.ucla.edu geoff@ITcorp.com