bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: touch problem?


From: Bob Proulx
Subject: Re: touch problem?
Date: Thu, 18 Jan 2001 09:36:31 -0700

> I found a behaviour of touch that I don't understand (It seems to me a 
> bug, at least a bug for the documentation) regarding the access, 
> modifications and change times attributes of a file.

The touch info page could be more explicit about this.  Right now it
only says it changes the access time (-a) or the modification time
(-m) and does not mention the statuc-change time since it cannot
directly effect it.  It is en environmental effect of the unix
kernel.

> I'm using a Debian GNU/Linux 2.2r2, linux 2.2.18, glibc 2.1 and the 
> problem is that if I get the file times after a touch also the ctime is 
> always changed.
[...]
> To get the file times I use this code (that seems fine to me):
> 
>      errstat = stat(argv[optind], &infos);
>      if (errstat!=0) {
>       perror("Error on stat calling");
>       exit(errstat);
>      }
>      printf("File %s stats results:\n", argv[optind]);
>      printf("     atime = %s", ctime(&infos.st_atime));
>      printf("     mtime = %s", ctime(&infos.st_mtime));
>      printf("     ctime = %s", ctime(&infos.st_ctime));

Note that for stat you can get all three times (atime, mtime, ctime)
all at once.  [As a small point I will point out that you should not
exit with the error status of stat.  That will usually be -1 and yet
program exits should only be in the range 0 to 255.  A simple exit(1)
or some such is probably the best program design in the general case.]

I find it interesting that for a kernel operation there are so many
places that could document it while having no ability to effect the
behavior.  It is a kernel system call after all.

> In the glibc documentation I found that:
[...more documentation describing kernel functionality...]
> According to this it doesn't seems to me that changing the change time 
> with touch is the right thing.

This is a kernel controlled behavior.  The utime(2) system call is
used to change times on a file.

I will refer to the online documentation at:

  http://www.unix-systems.org/single_unix_specification_v2/xsh/utime.html
  http://www.unix-systems.org/single_unix_specification_v2/xsh/utime.h.html

Also, Stevens has excellent information in Advanced Programming in the
UNIX environment.

#include <sys/types.h>
#include <utime.h>
int utime(const char *pathname, const struct utimbuf *times);

The structure used is:

struct utimbuf {
  time_t actime;  /* access time */
  time_t modtime; /* modification time */
}

Note that only two of the three times are available for modification.
You cannot set the status-change time (ctime).  That is the time the
inode was last changed.  That field is automatically updated when any
modification to the inode structure occurs, such as when utime is
called or chmod or any of the other system calls modify the inode
structure.

[Note that this is a basic design feature of the unix filesystem.  It
is a well known and documented interface which programs rely upon.
Many downstream ramifications occur because of this architecture.  For
example, many security programs count on the ctime changing and not
being user controllable.  If you could set it then you could in some
cases cover up a security incident.]

Hope that helps to explain the behavior.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]