severity 528126 normal
tag 528126 + moreinfo unreproducible
thanks
steve downes wrote:
> Touch does not update the timestamp in an existing file. This is
> particularly relevant to me as it appears to have caused dpkg to fail
> & not fully update leaving a none updatable system. I tested this both
> on the dpkg.log file & on another file. I also checked it worked on
> other hosts.
This seems very odd that the code would work correctly on everyone's
system except for yours. And even then it seems like it would be a
kernel problem with the utimesat call. Since this doesn't seem to be
widely a problem and because no other information has been provided
after Mike's follow-up I am marking this normal from severe.
> Setting up dpkg (1.14.26) ...
> touch: setting times of `/var/log/dpkg.log' : no such process
This comes from the dpkg.postinst script:
# Create log file and set default permissions if possible
create_logfile() {
logfile=/var/log/dpkg.log
touch $logfile
chmod 640 $logfile
chown root:adm $logfile 2>/dev/null || chown 0:4 $logfile
}
Mike already responded that he was unable to reproduce the problem. I
am unable to reproduce this problem. I am afraid you will need to
debug it or provide more information. In particular what is the
output of the trace command?
strace -v -o touch.strace touch foo
I expect to see something like this:
open("foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
dup2(3, 0) = 0
close(3) = 0
utimensat(0, NULL, NULL, 0) = 0
If the utimes et al system calls are failing then this is a kernel
problem and not an application problem.
Bob
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
