On Sun, Jan 02, 2011 at 09:19:30AM -0500, matthew sporleder wrote:
[TRYEMULROOT]
Since it's on http://www.netbsd.org/~dholland/buglists/file.html , I'm
sure you're aware of it, but would 41678 be solved?
http://gnats.NetBSD.org/cgi-bin/query-pr-single.pl?number=41678
Doubtful, as
On Sun, Jan 02, 2011 at 07:24:33PM +, David Holland wrote:
(Anyhow, like I wrote in that PR, the only real way forward for
onionfs is to try to figure out a self-consistent model for the
semantics. If as I suspect that turns out to be impossible, the right
way forward is to kill onionfs
On Sun, Jan 02, 2011 at 06:14:57PM +, David Laight wrote:
On Sun, Jan 02, 2011 at 09:52:31AM +, David Holland wrote:
Has anyone ever sat down and clearly worked out the desired semantics
for TRYEMULROOT? I've noted inconsistencies in the past, and because
in a number of ways
On Sun, 2 Jan 2011, David Holland wrote:
[...]
char last[NAME_MAX];
namei_parent(path, dvp, last, sizeof(last));
vn_lock(dvp);
VOP_MKDIR(dvp, last);
vn_unlock(dvp);
vrele(dvp);
which is simpler and a lot tidier, both on the surface and inside the
fs; however, if
On Sun, Jan 02, 2011 at 09:19:51PM +, Eduardo Horvath wrote:
TRYEMULROOT should only open existing objects on the emul path, it should
never create anything new, so you would never want to use it for mkdir.
I don't know if that means you need to pass an extra flag to
namei_parent()
