[OpenAFS-port-darwin] mv issues with panther and 1.2.10a ?

Alexei Kosut akosut@cs.stanford.edu
Tue, 13 Jan 2004 16:12:02 -0800


On Jan 13, 2004, at 3:41 PM, Chaskiel M Grundman wrote:
> --On Tuesday, January 13, 2004 13:44:32 -0800 Shantonu Sen 
> <ssen@mit.edu>
> wrote:
>> OpenAFS 1.2.10) and he was of the opinion that the patch suggested is 
>> too
>> severe, since it prevents proper operation when you have multiple root
>> volumes mounted. The patch in my bug only returns EXDEV if you're 
>> copying
>> from AFS to non-AFS.
>
> afs does not support VOP_RENAME() across volumes. I don't think it's
> necessary to support VOP_RENAME() between the same volume mounted in 
> two
> different places, but I'll let derrick make that decision.

The problem is that the mount entry attached to the vnode can be 
incorrect if you access the same volume twice through different 
mountpoints. It's been a while since I've thought about this, but I 
think the problem scenario went something like this:

1.  You access volume foo as /afs/foo/, and access with /afs/foo/file1. 
  The vnode for file1 is returned, with its v_mount pointing to 
/afs/foo.

2. You mount volume foo as /mnt/foo, and access with /mnt/foo/file1.  
The vnode for file1 now needs to have a v_mount pointing to /mnt/foo, 
so it gets changed.

3.  Now you do `mv /afs/foo/file1 /afs/foo/file2`.  The vnode for file2 
points to /afs/foo, but the vnode for file1 points to /afs/foo, so the 
cross-volume check fails.

I may have the details not quite right, but the scenario was something 
similar.  I know that saving files from TextEdit tended not to work if 
you had the same AFS directory available through two different 
mountpoints (Cocoa apps do an "atomic" save by saving to a temporary 
file and then renaming it.)

The problem is that the vnode cache doesn't know about multiple 
mountpoints, and I never got around to adding proper support for it.  
So the Darwin code tries to "fix" the v_mount whenever it gives them 
out, but since the OS holds onto them longer than just that call, they 
can become incorrect again.  This (renaming) was the only place I ever 
ran into where it was a problem, though.  After removing the check 
(which worked fine in Jaguar; I guess it's a problem in Panther), I 
didn't run into any more problems because of this, so I never got 
around to fixing it "correctly", which would probably involve having 
the vcache store separate vnodes for each mountpoint, rather than using 
the same one for each.

-- 
Alexei Kosut <akosut@cs.stanford.edu>