Forgot to 'cc' codalist on my initial reply, I hope Greg doesn't mind
that I've re-added codalist.

On Fri, May 24, 2002 at 02:24:13PM -0400, Greg Troxel wrote:
>   > So I am wondering if reintegration of symlinks is broken/backwards
>   > somehow.
> 
>   Interesting, I will look at it. Some changes went into reintegration
>   between 5.3.17 and 5.3.19. Yup, it looks like there is some confusion
>   between 'oldname' and 'newname' which probably should have been named
>   'name' and 'contents' to avoid confusion.
> 
> I hope you find something.

Yup, the bug seems to have been introduced around 2002/03/15 in venus.
Although it looks like the server might have been wrong in some places
as well. I went through the code and consistently used NewName as the
name to be created and OldName as the link contents. And actually
renamed these in the places I could easily do the renaming. Compiled it,
and will give it a try. I'm not sure whether it is a purely venus or
codasrv problem, I would have to read the diff to check that.

I'll commit the changes to CVS as soon as it looks like they work.

>   > Also, I think it is horribly broken that such objects prevent venus
>   > from restarting; this tends to make me blow my cache, and this
> 
>   I've tried several times to fix this 'symptom', but it only moves the
>   problem to another place. The real problem is the way local-global
>   repair moves objects into a fake volume, but never really moves them
>   back and relies on reintegration or object purge to lose these dangling
>   objects.
> 
> Well, if venus startup could cope with doing something safe with them,
> it would ease the pain of living with coda greatly.  Even just putting
> it back with a fake/uniquified name would help.  Or even deleting it -
> at this point I don't see how to get the bits out.   Perhaps I should
> know how to run norton, but the lack of a working 'fsck' type program
> is frustrating.  Am I correct that there is no real way to recover
> from such a state?

At first I tried to move the localized objects back to their real
volume, but some information is lost that makes it impossible/hard to do
right. Then I tried to simply destroy them to at least get venus back up
and running, which is why it is crashing now :(

>   Basically the 'localized' objects are moved into the local fake volume,
>   which used to be a replicated volume, although there is no backing
>   server for reintegration resulting in a lot of hacks and special cases.
>   When cleaning up the volume handling in the client I intentionally made
>   the local volume a non-replicated volume (i.e. one that cannot
>   reintegrate) which allowed me to remove all the special cases in the
>   reintegration code. However it revealed this bug, I'm noit going back to
>   making this volume replicated because we were both leaking memory and
>   silently corrupting various lists in the original volume. Not to speak
>   of all the hacks.
> 
> This makes sense.
> 
>   I hope at some point to continue with my cleanup of repair, pretty much
>   merging both local-global and server-server repair in such a way that
>   - we do not need to move real objects into the local volume. i.e.
>     everything in the local volume will be a fake object.
>   - we can repair a server-server conflict that might have caused the
>     local-global conflict in the first place instead of requiring another
>     client or a purgeml.
> 
> That would be cool.  Gradually de-hackifying coda is a good thing, but
> I know it is hard, just from the bit of code reading I've done.