mcm@rti.rti.org (Mike Mitchell) (03/15/91)
OK folks, here is a bug that has been around for awhile. I've verified that it is present in Ultrix 2.2, 3.1, and 4.1, on both Vaxes and DECstations. The problem is that 'creat' (or 'open' with the creat option) will cause the gnode modification time to be changed EVEN IF THE OPEN FAILS. This sounds a little weird, but here is an example to try to explain. Script started on Thu Mar 14 13:48:01 1991 # # mknod /tmp/buggy c 200 0 # ls -l /tmp/buggy crw-rw-r-- 1 root 200, 0 Mar 14 13:48 /tmp/buggy # sleep 60 # cp /etc/motd /tmp/buggy cp: /tmp/buggy: No such device or address # ls -lm /tmp/buggy crw-rw-r-- 1 root 200, 0 Mar 14 13:49 /tmp/buggy # ls -lc /tmp/buggy crw-rw-r-- 1 root 200, 0 Mar 14 13:49 /tmp/buggy # ls -lu /tmp/buggy crw-rw-r-- 1 root 200, 0 Mar 14 13:48 /tmp/buggy # rm -f /tmp/buggy #^D script done on Thu Mar 14 13:50:24 199 Notice that even though the copy failed, the 'ctime' and 'mtime' fields have been changed, but not the 'atime'. Here is a little script so you can try this at home. The script will have to be run as root, because only root can 'mknod'. #! /bin/sh mknod /tmp/buggy c 200 0 ls -l /tmp/buggy sleep 60 cp /etc/motd /tmp/buggy ls -lm /tmp/buggy ls -lc /tmp/buggy ls -lu /tmp/buggy rm -f /tmp/buggy Is there any hope that this bug will get fixed? Is there anyone at DEC really listening? I'd type this in as an SPR, but I've lost my typewriter. Besides, the last time I sent in an SPR, it took 2 months to get the orange acknowledgement copy back, then another 3 1/2 months to get a letter saying "Thank you for your problem report. ... The problem will be submitted to the review board for possible inclusion in the next release." It took almost six months for a letter saying the bug MIGHT be fixed in the next release! At least they did fix the bug in ULTRIX 4.0.... -- Mike Mitchell mcm@rti.rti.org uunet!rti!mcm "There's laughter where I used to see a tear. (919) 541-6098 It's all done with mirrors, have no fear."