(Illustration by Gaich Muramatsu)
On Mon, Jul 24, 2000 at 11:24:18AM +0100, Dr A V Le Blanc wrote: > I've still received no advice about this; did it get through > to the list? I can still not write any files in coda, though > I can delete files and create or delete directories. Well, it's just that I'm puzzled. On Wed, Jul 19, 2000 at 10:44:28PM +0100, Dr A V Le Blanc wrote: > On Thu, Jul 20, 2000 at 11:40:38AM -0400, Jan Harkes wrote: > > Is any activity in codacon indicating that venus tries to send a > > Create/Store to the server. > > Here is 'cp /etc/passwd .;rm passwd': > > Create passwd ( 23:10:23 ) > Store passwd [0] ( 23:10:23 ) This indicates that when Venus receives the close upcall, the container- file is zero length. I'll have to look whether some changes were made in 2.2.16 that are causing this. > > It looks like the create succeeds, but the store operation is completely > > failing. On what operation does it return EINVAL, > > `strace -e trace=file cp -p /tmp/wwwjob/Makefile' should show that. > > $ strace -e trace=file cp -p /etc/passwd . > execve("/bin/cp", ["cp", "-p", "/etc/passwd", "."], [/* 20 vars */]) = 0 > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/etc/ld.so.cache", O_RDONLY) = 3 > open("/lib/libc.so.6", O_RDONLY) = 3 > lstat(".", {st_mode=S_IFDIR|0711, st_size=2048, ...}) = 0 > stat(".", {st_mode=S_IFDIR|0711, st_size=2048, ...}) = 0 > stat("/etc/passwd", {st_mode=S_IFREG|0644, st_size=1104, ...}) = 0 > stat("./passwd", 0xbffff7dc) = -1 ENOENT (No such file or directory) > open("/etc/passwd", O_RDONLY|0x8000) = 3 > open("./passwd", O_WRONLY|O_CREAT|O_TRUNC|0x8000, 0600) = 4 > utime("./passwd", [2000/07/20-23:10:23, 2000/07/19-00:01:34]) = 0 > chown("./passwd", 102, 0) = 0 > chmod("./passwd", 0100644) = 0 > $ Didn't see any of the read/write/close calls here, I figured that the open() or close() calls would be failing, but from this trace it looks like nothing is wrong. > [ H(07) : 0005 : 23:10:13 ] binding::~binding: somebody forgot to decrement before delete These are always there around disconnections, they indicate that some reference counting went wrong, but they are reasonably harmless. > and I guess these are from about the time of the problem: > > [ D(02) : 0197 : 23:10:34 ] NotifyUserOfServerBandwidthEvent > [ D(02) : 0199 : 23:10:49 ] NotifyUserOfServerBandwidthEvent > [ T(01) : 0203 : 23:11:29 ] BeginRvmTruncate (173, 4116, I) > [ T(01) : 0203 : 23:11:30 ] cache::EndRvmTruncate > [ W(20) : 0000 : 23:12:25 ] Cachefile::SetLength 0 Yes, after the close, venus stat(2)'s the containerfile and at that time it has a size of 0 bytes. I'll install a 2.2.16 kernel today to see if I can reproduce the problem. JanReceived on 2000-07-24 08:51:03