xmh and utime()
bec...@cs.rochester.edu
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.
bec...@cs.rochester.edu
weissman@decwrl
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 weis...@decwrl.dec.com ...!decwrl!weissman
bec...@cs.rochester.edu
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.
bec...@cs.rochester.edu
PS. I love the *speed* of xmh. I do have some problems with it still, but it
looks wonderful. Thanks!
Guy Harris
> 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
g...@sun.com
Jeff Morris
Newsgroups: comp.windows.x
Subject: Re: xmh and utime()
Summary: System V
Expires:
References: <870922211...@gilroy.dec.com> <870922212...@wasat.cs.rochester.edu>
Sender:
Reply-To: j...@comvme.UUCP (Jeff Morris)
Followup-To:
Distribution: world
Organization: Motorola Microcomputer Division, Tempe, Az.
Keywords:
.In article <870922212...@wasat.cs.rochester.edu> bec...@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.
.>bec...@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.
b...@wiley.uucp
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
b...@wiley.uucp
{csvax.caltech.edu,trwrb.uucp}!wiley!bob
bilbo...@cs.ucla.edu.uucp
> 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 ge...@lcc.ucla.edu ge...@ITcorp.com