On Thu, Mar 06, 2003 at 05:14:26PM +0100, Steffen Neumann wrote:
> Jan Harkes <jaharkes_at_cs.cmu.edu> writes:
> > I will probably create 'rename name' operation for norton that can be
> 'Till then we'll live with those files,
> and hop they don't screw up the server.

Hmm, it looks like I don't really have to implement a rename function
because we already have 'create name' and 'delete name'. We can't just
use 'delete name' because that would leave an unconnected object in
in the volume and the server doesn't like that during startup.

In any case, get the fid of the directory that has the bad filenames
which is simpler when the server is still up.

    client# cfs getfid /coda/vol/kernel/src/ltmodem-6.00b7

Now this gives us the replicated volumeid, and later on we actually need
the volumeid of the underlying replica. I typically just look that one
up in /vice/db/VRList.

Now shut down the server.
    
    server# volutil shutdown

Check where rvm log and data are located and what the 'configured' size
of the RVM data partition is. This is typically in /etc/coda/server.conf,
but if you have an older setup could also be in /vice/srv.conf.

Start norton, the parameters I use here are of one of my testservers
where I tried to do all of this.

    server# norton /vice/LOG /vice/DATA 136314880

    # now we can check if we actually have the right directory.
    norton> show directory 0xe60000002 0x1 0x1
	(0x7 0xec)  pam_kcoda-v0.4
	(0xa 0xcc)  pam_kcoda-v0.4.tgz
	(0x1 0x1)   .
	(0xb 0x179c)        coda
	(0x1 0x1)   ..
    
    # next step is to create an alternative name to one of the objects.
    # basically 'create name' in directory object 0x6e000001.0x1.0x1 where
    # the name is 'foo' and it points at the object 0x6e000001.0xa.0xcc
    norton> create name 0xe6000002 0x1 0x1 foo 0xa 0xcc
    norton> show directory 0xe6000002 0x1 0x1
	(0x7 0xec)  pam_kcoda-v0.4
	(0xa 0xcc)  pam_kcoda-v0.4.tgz
	(0x1 0x1)   .
	(0xb 0x179c)        coda
	(0x1 0x1)   ..
	(0xa 0xcc)  foo

    # now we are ready to remove the bad name :)
    # the '0' at the end just needs to be a '0', the directory link count
    # would get messed up if you use something else. 
    norton> delete name 0xe6000002 0x1 0x1 pam_kcoda-v0.4.tgz 0
    norton> show directory 0xe6000002 0x1 0x1
	(0x7 0xec)  pam_kcoda-v0.4
	(0x1 0x1)   .
	(0xb 0x179c)        coda
	(0x1 0x1)   ..
	(0xa 0xcc)  foo

    norton> q

Now the annoying thing is that norton marks the directory object as
inconsistent, this way when you have replicated servers, you are forced
to use repair to make sure that all servers are looking at the same
directory data.

In any case, we can restart the server here and it should come up just
fine. When we look at the directory it is in conflict. (i.e. the
dangling symlink). With a replicated volume, normal repair should just
work fine. I'm currently looking at why repair is not doing the right
things on singly replicated volumes when resolution is turned off.

Jan