>On Wed, Jul 25, 2001 at 02:25:19PM -0700, David Greenman wrote:
>>Guessing, I think the correct fix is probably to set the IN_ACCESS flag in
>> ufs_open() [and similarly with other filesystems where this makes sense] if
>> the filesystem is not mounted with the noatime flag. However, I'm not
> On Thu, Jul 26, 2001 at 12:09:17PM +0100, David Malone wrote:
> > On Wed, Jul 25, 2001 at 02:25:19PM -0700, David Greenman wrote:
> > >Guessing, I think the correct fix is probably to set the IN_ACCESS flag
> > > ufs_open() [and similarly with other filesystems where this makes sense] i
> >
On Thu, Jul 26, 2001 at 12:09:17PM +0100, David Malone wrote:
> On Wed, Jul 25, 2001 at 02:25:19PM -0700, David Greenman wrote:
> >Guessing, I think the correct fix is probably to set the IN_ACCESS flag in
> > ufs_open() [and similarly with other filesystems where this makes sense] if
> > the
On Wed, Jul 25, 2001 at 02:25:19PM -0700, David Greenman wrote:
>Guessing, I think the correct fix is probably to set the IN_ACCESS flag in
> ufs_open() [and similarly with other filesystems where this makes sense] if
> the filesystem is not mounted with the noatime flag. However, I'm not sure
>>Hmm... would it be as easy as
>>VOP_GETATTR();
>>.
>>.
>>.
>>VOP_SETATTR();
>>
>>within the exec() code?
>>
>>Certainly this would be an 'easy' fix (and I can work up diffs for review),
>>but is it the 'correct' fix?
>
> No, it's not the correct fix. You shouldn't need to do the GETATTR first,
>Hmm... would it be as easy as
>VOP_GETATTR();
>.
>.
>.
>VOP_SETATTR();
>
>within the exec() code?
>
>Certainly this would be an 'easy' fix (and I can work up diffs for review),
>but is it the 'correct' fix?
No, it's not the correct fix. You shouldn't need to do the GETATTR first,
and doing a
Hmm... would it be as easy as
VOP_GETATTR();
.
.
.
VOP_SETATTR();
within the exec() code?
Certainly this would be an 'easy' fix (and I can work up diffs for review),
but is it the 'correct' fix?
--
David Cross | email: [EMAIL PROTECTED]
Lab Director
On Wed, 25 Jul 2001, David E. Cross wrote:
> In my case it would be usefull as I was trying to tell the last time
> 'telnetd' was run. (yes, not perfect, but better than nothing)
well, for caching file systems it is very useful to have an exec set
atime. Helps you figure out which files can be p
In my case it would be usefull as I was trying to tell the last time
'telnetd' was run. (yes, not perfect, but better than nothing)
--
David Cross | email: [EMAIL PROTECTED]
Lab Director | Rm: 308 Lally Hall
Rensselaer Polytechnic Instit
>I noticed that exec(2) does not update the last access time of a file...
>is this intentional?
Not exactly intentional (I never had that as a goal when I wrote execve()),
but it's a side-effect of exec not doing a 'read' on the file in the
traditional sense. This has been discussed several ti
"David E. Cross" wrote:
> I noticed that exec(2) does not update the last access time of a file...
> is this intentional?
POSIX only mandates updates of time fields in very specific
cirumstances: when using particular API's.
So if you use a different or unexpected API, an update is
not required.
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> What about under solaris UFS?
Yes, it does update the atime.
And most Unixes seem to do the same thing.
/assar
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
* David E. Cross <[EMAIL PROTECTED]> [010724 20:16] wrote:
> Well over NFS an exec will update atime (because NFS doesn't differentiate
> between 'exec' and 'read').
>
> Under Solaris8/Sparc (on a memfs mount) exec-ing an executable does indeed
> update the access time.
What about under solaris
Well over NFS an exec will update atime (because NFS doesn't differentiate
between 'exec' and 'read').
Under Solaris8/Sparc (on a memfs mount) exec-ing an executable does indeed
update the access time.
--
David Cross | email: [EMAIL PROTECTED]
Lab Director
* David E. Cross <[EMAIL PROTECTED]> [010724 19:35] wrote:
> I noticed that exec(2) does not update the last access time of a file...
> is this intentional?
atime was implemented to satisfy a specification (which stinks),
I would track down the specification and see, either that or compare
agains
I noticed that exec(2) does not update the last access time of a file...
is this intentional?
--
David Cross | email: [EMAIL PROTECTED]
Lab Director | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
16 matches
Mail list logo
