[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>