Date: Tue, 19 Sep 2006 18:27:39 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: current@FreeBSD.org Subject: Re: VFS(?) weirdness Message-ID: <20060919142739.GM27667@cell.sick.ru> In-Reply-To: <20060919140953.GA46227@walton.maths.tcd.ie> References: <20060919133702.GJ27667@FreeBSD.org> <20060919140953.GA46227@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 19, 2006 at 03:09:53PM +0100, David Malone wrote: D> On Tue, Sep 19, 2006 at 05:37:02PM +0400, Gleb Smirnoff wrote: D> > Dear collegues, D> > D> > I've got a box running HEAD where a strange bug is observed. The below D> > script always returns on this box: D> > D> > pwd: .: Permission denied D> D> I've tried this on a current machine (as of Sept 16th) and don't D> see the same thing. Yep, this box is the only one I observe the bug on. :( I've observed it last few months, and I update to HEAD weekly. Moreover, the /home/glebius directory on thix box is NFS exported and mounted on another box as /home/glebius. On this other box (NFS client) I run th test successfully from /home/glebius, while on NFS server it fails. D> I'd guess this is somehow related to the fact that removing a D> directory flushes the nami cache for things related to that directory's D> parent. This probably results in the kernel getcwd failing and it D> falling back to the userland getcwd code, which needs to read and D> stat every directory above you in the filesystem tree. Do you have D> a directory further up your path that isn't readable/statable? Yes. I can reproduce it in my home, or in /tmp. All upper directories are readable. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060919142739.GM27667>