On Sat, 28 Aug 2021, J. Bruce Fields wrote:
> On Fri, Aug 27, 2021 at 08:10:38AM +1000, NeilBrown wrote:
> > On Fri, 27 Aug 2021, J. Bruce Fields wrote:
> > > On Thu, Aug 26, 2021 at 04:03:04PM +1000, NeilBrown wrote:
> > > > + }
> > > > + if (resp->dir_ino_uniquifier != ino)
> > > > + ino ^= resp->dir_ino_uniquifier;
> > >
> > > I guess this check (here and in nfsd_uniquify_ino) is just to prevent
> > > returning inode number zero?
> >
> > Yep. The set of valid inode numbers is 1..MAX and that set isn't closed
> > under xor.
>
> I was curious....
>
> The NFS specs don't require FILEID to be nonzero as far as I can tell.
>
> Our client doesn't treat fileid 0 specially. In the case it has to
> return a 32-bit inode it xors the high and low parts and makes no effort
> I can see to check for the 0 case.
>
> I modified a server to return 0 for FILEID and MOUNTED_ON_FILEID on one
> particular file, and an strace shows that's happily passed on to
> userspace:
>
> getdents64(3, [..., {d_ino=0, d_off=2048, d_reclen=32,
> d_type=DT_REG, d_name="LOCKTESTFILE"}]
>
> But ls silently skips that file in the output. Huh.
>
What DO they teach in history class?
The original Unix File System (edition 6, 7 at least) had 16 bytes per
entry in directories (that could be read with read(2)). Two bytes of
inode number and 14 bytes of name.
When a name was deleted, the inode number was over-written with '0'.
So code - and coders - from that era ignore directory entries with
d_ino==0.
I'm not certain what inode 0 was used for, but I think it had some
behind-the-scenes role. Free-space?
So some code might work find with ino==0, but I'd rather not risk it.
NeilBrown
