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 =3D=3D 0. If root does a getdents() it returns a 0 reply instead of the directory blo= ck with "." and ".." in it. I think this explains why "ls -a" shows nothing, b= ut 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 err= or (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>