> Ah, the CML is owned by the user that made the changes, the error log
> file (/usr/coda/etc/console or /var/log/coda/venus.err) may contain some
> indication about that fact,
>
>     Reintegrate <volume name> pending tokens for uid = <local uid>
>
I am not at home and I can not test what you told me, but I can give some
extra info :
Yes there is such a line (vol u.natalia and uid 1001). But the cache files
belongs to root:staff and event if I connect with the 1001 uid (natalia),
venus tell me it reintegrate changes, but nothing happens. No CML are
reintegrated, no network transfert occurs and the same message will
happen, later.

> If this is the case it should be as simple as getting tokens for that
> local user. Another reason for not reintegrating may be that there is a
> conflict, this should also get logged in probably in venus.log. Conflict
> repair can be tricky especially when there are potentially a lot of
> conflicts (up to 4914 in your case). In either case you should be able
> to run

No conflict possible : I began all my backup with a purge of the volume.
>From another client, I removed all the files/directories in it and
reintegrated ALL the CML. From a third client, I connected and the volume
was empty. So, all the file I copied in the replicated volume are new one.

>     cfs checkpointml /coda/.../natalia
>
> which will create a local checkpoint (tar archive) that contains all the
> files that we failed to reintegrate. This can be found as
>     /usr/coda/spool/<local uid>/<volume name>.tar, or
>     /var/lib/coda/spool/<local uid>/<volume name>.tar

This Idea is very interesting if the tarball reflect the real tree of
directories. I will try this evening, but I think it will not work. In
fact, Venus seems not to be able to access this volume anymore. But I dont
know the origin of the problem (corrupt files in RVM or Cache...). So
whatever the tree in the archive, I dont think venus will be able to build
it. I hope, I will try and tell you.

> If you were mostly creating files and everything is in that tar archive
> then it is possible to copy that tarball to a safe place and purge the
> modification log, or restart venus with a -init flag to really wipe it's
> memory. And then untar the archive to get the remaining files copied.
I did not try a -init yet, but I prepared a full copy of the cache & spool
dir in order to restore it. I suppose that the tarball is to be untared in
the cache dir ?

>
>     cfs purgeml /coda/.../natalia  # flush all non-reintegrated updates.
>
> If you still have the original data around, it may just be simplest to
> purge the CML / reinitialize venus, and use rsync -av to resume the
> copy, that should check if all the existing files were copied correctly
> by calculating it's checksum.

If only... I trusted coda and made a "mv" ! All my data are in this damn
cache dir ! :-(

I'll try the checkpoint method this evening and tell you what happens.

-- 
Francois Cerbelle
Bat. B10 - 6 r d'Andilly - 95600 Eaubonne
SFR: (+33/0) 603 015 512 - FBX: (+33/0) 871 777 756