Date: Wed, 13 Sep 1995 10:41:43 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: davidg@root.com, terry@lambert.org, current@freebsd.org, mckusick@mckusick.com Subject: Re: BAD BUG IN UFS RENAME Message-ID: <199509131741.KAA07728@phaeton.artisoft.com> In-Reply-To: <199509131058.UAA05201@godzilla.zeta.org.au> from "Bruce Evans" at Sep 13, 95 08:58:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Nope, there are several known msdosfs rename bugs, all known to be > different. (E.g., one is also a ufs rename bug: things have to be unlocked > before calling checkpath() to avoid deadlock, but this allows races > in checkpath(). Bad effects are easy to demonstrate by putting a tsleep() > in checkpath() before the call to VFS_VGET() and removing a critical > file or directory during the simulated blockage of VFS_VGET().) I was wondering why the hell this was. As far as I can tell, ufs_rename() in ufs_vnops.c is the only consumer of ufs_checkpath() in ufs_lookup.c. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509131741.KAA07728>