Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.questions
Subject: Re: How to make sendmail re-read the configuration file (and cron)
Message-ID: <5128@mimsy.UUCP>
Date: Tue, 20-Jan-87 07:44:22 EST
Article-I.D.: mimsy.5128
Posted: Tue Jan 20 07:44:22 1987
Date-Received: Tue, 20-Jan-87 23:54:16 EST
References: <136@quacky.mips.UUCP> <201@devon.UUCP> <2409@mcc-pp.UUCP>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 20
Summary: stat follows symlinks, lstat does not

In article <2409@mcc-pp.UUCP> ables@mcc-pp.UUCP (King Ables) writes:
<... I've got a bunch of diskless suns and rather than have a
<different crontab for all the suns on a server, I have all clients
<crontabs point to the real crontab file.  However, when I make a
<change, it doesn't seem to take unless I kill the cron daemon.
<I never even thought of stat()!  Of course, it's stat()ing the
<symbolic link (which hasn't changed!) and not the real file.

That is rather strange if it is.

<Now, the question I have is why would you ever NOT want stat()
<to resolve the link and stat the actual disk file rather than the
<link???

Why?  Suppose you want to find out about the link.  In this case,
use lstat(), which does not follow the link.  The stat() call does
indeed follow symbolic links `and stat the actual disk file'.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu