Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rpi!brutus.cs.uiuc.edu!wuarchive!mit-eddie!rutgers!soleil!slopoke.semi.harris-atd.com!thrush!del
From: del@thrush.semi.harris-atd.com (Don Lewis)
Newsgroups: comp.unix.wizards
Subject: Re: What new system calls do you want in BSD?
Message-ID: <1990Feb8.080645.4458@semi.harris-atd.com>
Date: 8 Feb 90 08:06:45 GMT
References: <12157@stealth.acf.nyu.edu> <1990Jan24.193433.3332@semi.harris-atd.com> <23449@stealth.acf.nyu.edu>
Sender: news@semi.harris-atd.com
Distribution: usa
Organization: Harris Semiconductor, Melbourne, FL
Lines: 22

In article <23449@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
>In article <1990Jan24.193433.3332@semi.harris-atd.com> del@thrush.semi.harris-atd.com (Don Lewis) writes:
>>   open(file,O_PEEK)
>
>This could be a flag on any open, meaning simply ``update ctime rather
>than atime or mtime.'' Crackers already know about utimes(); perhaps an
>O_PEEK flag would educate inexperienced sysadmins.
>
>---Dan
I don't want it to update the ctime either.  I shouldn't have to dump the
file just because someone read it.  It only needs to keep atime from being
changed if you read the file.  If you write to the file, it is still ok
to change ctime and mtime.   I'm looking to preserve the atime so I can still
find unused files (candidates for deletion) even if the hierarchy containing
them has been tar'ed or cpio'ed.  Besides, it's a performance win because
the kernel doesn't have to go back and update all those inodes, sort of like
treating the filesystem as read-only.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@semi.harris-atd.com     PO Box 883   MS 62A-028
UUCP:      rutgers!soleil!thrush!del   Melbourne, FL  32901              
Phone:     (407) 729-5205