(Illustration by Gaich Muramatsu)
Hello, I'm here to bother you with the same things again and again :) Sorry for that but I assume the developers want to know - symbolic link traversal during exec() is unreliable. I have seen it during concurrent shared library access before. Today I have observed it even on a disconnected Coda client as access failure to run "sed" during "./configure.status" (on a local filesystem). sed is run from Coda: PATH is pointing to a Coda directory with a symbolic link pointing to a shell wrapper (in Coda too), doing "exec" of the actual sed binary (in Coda, too). That is, three different places in Coda are concerned. Let us call the places A, B and C: PATH=/coda/A /coda/A/sed -> /coda/B/sed /coda/B/sed: #!/bin/sh exec /coda/C/sed "$@" Well, *sometimes* I get a message: can not execute /coda/A/sed: no such file or directory (yes, A) while the file is perfectly accessible otherwise. The problem is much more seldom on a disconnected client but I have seen it many times. On a connected client I can't run configure scripts at all if they run sed multiple times, as they break at random places. (Why is it just sed that breaks? I run virtually all programs in that three-step way, and it works. Probably configure runs sed in a pipeline, i.e. more than one sed concurrently...) Hope it helps. Another thing - if I let compilations or similar massive updates on /coda run without "cfs strong; cfs wf -on", venus dies rather soon after several "reintegration: Success" messages, with Signal 11. Venus 5.3.17 on Linux kernel 2.4.14 and 2.4.17 exactly the same behaviour. (Server and kernel module 5.3.15) Best regards, -- IvanReceived on 2002-01-05 18:25:50