On Thu, Jul 07, 2016 at 10:09:49PM +0200, Karl-Philipp Richter wrote:
> I'm having trouble figuring out whether I found a bug or am not
> understanding well how data storage works. After stopping
> `coda-client.service` (`coda-server.service` doesn't work because of
> https://github.com/cmusatyalab/coda/issues/10), removing all directories
> (/vice/, data and log directory) configured in `vice-setup`, running
> `vice-setup` again with the same directory arguments I'm still seeing

Just restarting the client doesn't get rid of the persistent state. A
client needs to start with the '-init' flag, or an empty file named INIT
should be created in the client's "spool" directory where the container
files are stored (/var/lib/coda/spool). Then when the client is
restarted it will clear the state in recoverable memory.

>     $ ll /coda/richtercloud.de/
>     ls: cannot access '/coda/richtercloud.de/home': No such file or
> directory
>     total 5
>     drwxr-xr-x 1 root    nogroup 2048 Jun 10 01:49 .
>     dr-xr-xr-x 1 root    nogroup 2048 Jun  1 02:58 ..
>     ?????????? ? ?       ?          ?            ? home
>     lrw-r--r-- 1 richter nogroup   16 Jun 10 01:44 virtualbox-vms ->
> #virtualbox-vms
>     lrw-r--r-- 1 richter nogroup   17 Jun 10 01:49 virtualbox-vms1 ->
> #virtualbox-vms1
> 
> which looks like remainders of my previous volumes. How is this possible
> after complete removal of information?

Well, if there is a newly initialized server running it might be using
the exact same version vector on the same object identifier (volume root
always uses vnode 1, uniquefier 1), but that case is unlikely.

The more likely scenarios are that either there is no running server and
the client is in fully disconnected mode, or local changes were made on
the client that have not been reintegrated to the server (many possible
reasons, disconnection before reintegration completed, lack of or
expired authentication token, underlying server conflict) and the client
is in write-disconnect mode where all the 'dirty' objects associated
with not yet reintegrated changes and which only exist on your client
are preventing you from seeing the actual server state.

Running things like 'cfs checkservers', and 'cfs listvol
/coda/richtercloud.de/' should give an idea of what is going on.

Running 'codacon' in an xterm window can be helpful too, it gives
ephemeral information such as server disconnections/reconnections,
reintegration state and I think an indication when tokens expire.

If there are unreintegrated changes, either discard them with 'cfs
purgeml /coda/richtercloud.de', or just restart venus with the INIT file
or -init flag to wipe any persisted local changes.

Jan