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,
--
Ivan