Date: Wed, 21 Dec 2016 23:52:59 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Don Lewis <truckman@FreeBSD.org> Cc: "cperciva@tarsnap.com" <cperciva@tarsnap.com>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: ESTALE after cwd deleted by same NFS client Message-ID: <YTXPR01MB018914D6FCE0D3009FE1AD0EDD930@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <201612210325.uBL3PVtg006345@gw.catspoiler.org> References: <YTXPR01MB0189BA6B72E77E1C1D16CE83DD900@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>, <201612210325.uBL3PVtg006345@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Don Lewis wrote:
[stuff snipped]
> Dunno how ufs and zfs handle this, but the right thing happens:
>
> %mkdir /tmp/barf1
> %cd /tmp/barf1
> %rmdir /tmp/barf1
> %touch barf2
> touch: barf2: No such file or directory
> %ls
I tried this as "root" (the only user that matters;-) on a UFS file system and got the
above, but also observed a couple of interesting things:
1 - "ls -a" returned without showing "." or "..".
2 - "cat -v ." worked and showed a directory block with "." and ".." in it.
The entries looked valid and did not have d_fileno == 0.
If root does a getdents() it returns a 0 reply instead of the directory block
with "." and ".." in it. I think this explains why "ls -a" shows nothing, but does
not see an error. (getdents() would return -1 for an error, but it returns 0
for EOF on the directory.)
I suppose that nfs_readdir() could fake #1 by just returning without an error
(ie no data) when it gets ESTALE. I don't think support of #2 is required?
Not a POSIX guy, so I don't know what POSIX defines/expects for this case?
rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB018914D6FCE0D3009FE1AD0EDD930>