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
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
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
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.
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
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
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
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
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 SETATTR
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 SETATTR
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
* 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
against
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 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 UFS?
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
15 matches
Mail list logo