Hello,

seeing some points I'd like to comment on (my problem with upgrade from 
.11 to .12 miraculously went away after I rebooted all servers several 
times to get fresh logs for Jan, now it's just tons of repairs, thanx 
still :).

> There are several big hurdles we have taken and still have to take to
> get Coda nicely integrated on Windows platforms.

Maybe focusing on NTs/2Ks would make more sense ? I mean, I don't see 
much point in trying to bend over backwards to accomodate an outdated 
virtual machine concept ?

> The only effect that clock skew has is when applications that use RVM
> are restarted and the time has warped back. The client-server
> interaction has definitely no time dependent parts, we wouldn't even
> dare consider calling this a _Distributed_ File System if it did. 

I have different experience here. I had definite problems when one of 
the replicated servers had a date set one day back compared to all the 
others. Mostly it was loosing authentication tokens some time in the 
middle of working with the volume (empirically, it was when the one 
server with wrong time figured the token should expire), which caused 
"false" conflicts to appear, and made the system basically unusable. 
After syncing all with NTP the problems went away.

Also, seeing how Jan really reads this, I thought to add a few more 
observations:

I definitely agree the documentation should be updated. At least the 
"quick install" guide. What I personally missed in my hmm, month or so ? 
with Coda, was:

  - Outdated installation instructions. In the end, it turned out to be 
just "rpm -U coda*.rpm", but I kept worrying if it is really so easy 
when all the docs says things should be started manually (not through 
rc.d scripts) etc.

  - Also, I tended to get myself lost in the various IDs used. After 
several adds and removes of volumes, I kinda figured it out, but a few 
lines in the docs (e.g. that one is supposed to come up with IDs of 
groups for VSGDB) would help.

  - The documentation seems to give the system a more unstable feel than 
it probably deserves. One example I recall is the private mmap support, 
which I did not dare try due to warnings in the config file comments, 
but switched to after I saw a message here that suggested it should work 
OK, and it was a great improvement (one of my servers is low on memory 
and this helped a lot).

I also encountered the problem with local vs. fully qualified hostname. 
What seems to work is keep /vice/hostname short and names in server list 
and everywhere else long. This is something one has to do manually after 
install.

There are bugs in scripts. At my servers, purgevol_rep (or whatever is 
the script for deleting volumes called) fails, obviously looking for 
some list of volumes that does not exist in the current version.

This, however, was all things one could kinda sorta work around. What I 
have a biggest problem with is the repair tool. I run three servers in 
an environment where very often, one or two are inaccessible (but there 
are never concurrent updates from more clients). When conflicts occur, 
the repair tool often fails to fix them, and I usually end up with doing 
"beginrepair", copying all the copies somewhere else, doing "removeinc" 
and copying the data back (sometimes, "removeinc" fails on one server 
but not on another, etc.).

---

BUT ! It still seems to work and is usable ! (at least on my platform, I 
really didn't try Windows)

The questions I'm running into now are more of the sort, is Coda really 
the system I was looking for in my particular situation ? I have three 
machines I work on, geographically distant and not always connected very 
well. I used to have a script that used rsync to keep the home 
directories synchronized, but this was not really reliable (rsync has 
problems with links, changes that involve modifying directory structure, 
and bidirectional updates, among others).

I switched to Coda, and made all the three computers servers (in hope of 
having the updates always propagated to at least one server when the 
network is down). This seems to work nicely, except for the following:

  - I have to use write disconnected mode, otherwise the delays in 
propagating the updates to all the servers are too big. In that mode, 
however, conflicts appear much more often (and even in situations where 
I don't think they should).

  - Some of the files I have are logs, of several megs in size, that 
only get appended to. In the write disconnected mode, it seems that the 
updates are propagated in form of entire files, not just change logs, 
which means huge amounts of data get passed over the net for even small 
changes. (Just a hunch looking at the network traffic.)

  - I use up twice as much disk space, because I have both the client 
and the server running on a machine where I'd normally have just one 
copy of the data.

Now, did I pick Coda right, or am I trying to use it in a situation 
where something else (what ?) would be better ?

Petr Tuma