Date: Tue, 2 Oct 2001 10:33:58 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/ufs/ufs ufs_vnops.c Message-ID: <200110021733.f92HXwI58562@earth.backplane.com> References: <18752.1002008770@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:In message <200110020426.f924Qw605686@freefall.freebsd.org>, Matt Dillon writes
::
:>dillon 2001/10/01 21:26:58 PDT
:>
:> Modified files:
:> sys/ufs/ufs ufs_vnops.c
:> Log:
:> Backout the last commit. The problem is actually much worse then I
:> first thought and may require serious work to the VOP_RENAME() api itself.
:> Basically, by the time the VOP_RENAME() function is called, it's already
:> too late.
:
:I chatted with Rob Pike about rename, in particular in the context of
:remote filesystems and plan9.
:
:To avoid the nightmare of our VOP_RENAME, in plan9 you can only rename
:inside one directory.
:
:While not an option for us, I can certainly see why they did that...
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
'nightmare' is exactly the right word. There is no simple fix to
this... by the time VOP_RENAME is called, it's already too late.
Even flagging the vnode representing the source in the namei() call
itself, prior to unlocking it, is not sufficient because the relookup()
inside VOP_RENAME will still fail if someone renames one of the parent
directories in the source path.
We can't lock the source dir/vnode AND the destination dir/vnode because
of the potential to deadlock with other processes.
We can't switch around which one the syscall locks (lock the source
instead of the destination) without changing the VOP_RENAME api.
We can't undo the UFS code - it does (and must do) the relookup after
linking the destination.
In short, we're screwed.
I am going to attempt to do a workaround that checks the link count
in the inode to determine if the rename() can proceed after the
relookup() call fails.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110021733.f92HXwI58562>