On Sun Nov 11 2007 at 21:29:15 +0000, Alistair Crooks wrote:
> > > > Only use the bottom 5 bits of the random number, to prevent inode
> > > > numbers creeping outside of the range fts considers normal.
> > > 
> > > Duh, 20bits, changed in repository.
> > 
> > Surely we now support 64bit inode numbers ?
> > So what is fts complaining about ?
> 
> I'll show you what happened, in chronological order:
> 
> First problem:
> 
> 	[9:06:35] agc@inspiron1300 ...examples/refuse/iscsi-initiator 405 > l -R /mnt
> 	total 66
> 	drwxr-xr-x   2 root  wheel     0 Jan  1  1970 .
> 	drwxr-xr-x  34 root  wheel  1536 Nov  8 19:29 ..
> 	drwxr-xr-x   2 agc   agc     512 Nov  9 17:55 inspiron1300.wherever.co.uk
> 
> 	/mnt/inspiron1300.wherever.co.uk:
> 	total 128
> 	drwxr-xr-x  2 agc   agc    512 Nov  9 17:55 .
> 	drwxr-xr-x  2 root  wheel    0 Jan  1  1970 ..
> 	drwxr-xr-x  2 agc   agc    512 Nov  9 17:55 target0
> 	ls: target0: directory causes a cycle
> 	[9:06:52] agc@inspiron1300 ...examples/refuse/iscsi-initiator 406 >
> 
> As a background, I tracked this down to the FTS_C case in ls(1).
> I surmised that it was caused by the fact that the virtual dir routines
> used the same inode number for each directory. Up until now, I'd been
> using a different version of ls(1).
> 
> I committed the version of the virtdir routines with the random inode
> number (virtdir.c rev 1.7), and restarted the iSCSI initiator.  Trying
> to do a recursive listing of the directory tree now worked fine:

Note that you should be using the same inode number both in getattr and
readdir for the same node or pwd will not work.

> Unfortunately, tab completion in the shell couldn't find the regular
> file in the directory, and neither could ls:
> 
> 	[9:25:54] agc@inspiron1300 ...examples/refuse/iscsi-initiator 431 > priv vnconfig vnd0 /mnt/inspiron1300.wherever.co.uk/storage
> 	vnconfig: /mnt/inspiron1300.wherever.co.uk/storage: No such file or directory
> 	[9:26:52] agc@inspiron1300 ...examples/refuse/iscsi-initiator 432 > l /mnt/inspiron1300.wherever.co.uk/target0/
> 	hostname@   ip@         product@    storage     targetname@ vendor@     version@
> 	[9:26:52] agc@inspiron1300 ...examples/refuse/iscsi-initiator 432 > l /mnt/inspiron1300.wherever.co.uk/target0/
> 	total 576
> 	drwxr-xr-x  2 agc  agc        512 Nov  9 17:55 .
> 	drwxr-xr-x  2 agc  agc        512 Nov  9 17:55 ..
> 	lrw-r--r--  1 agc  agc         44 Nov  9 17:55 hostname -> inspiron1300.wherever.co.uk
> 	lrw-r--r--  1 agc  agc          9 Nov  9 17:55 ip -> 10.4.0.42
> 	lrw-r--r--  1 agc  agc         16 Nov  9 17:55 product -> NetBSD iSCSI
> 	-rw-r--r--  1 agc  agc  104857088 Nov  9 17:55 storage
> 	lrw-r--r--  1 agc  agc         43 Nov  9 17:55 targetname -> iqn.1994-04.org.netbsd.iscsi-target:target0
> 	lrw-r--r--  1 agc  agc          8 Nov  9 17:55 vendor -> NetBSD
> 	lrw-r--r--  1 agc  agc          4 Nov  9 17:55 version -> 0
> 	[9:27:03] agc@inspiron1300 ...examples/refuse/iscsi-initiator 433 > l -i /mnt/inspiron1300.wherever.co.uk/target0/
> 	total 576
> 	1804289383 drwxr-xr-x  2 agc  agc        512 Nov  9 17:55 .
> 	 846930886 drwxr-xr-x  2 agc  agc        512 Nov  9 17:55 ..         
> 	1714636915 lrw-r--r--  1 agc  agc         44 Nov  9 17:55 hostname -> inspiron1300.wherever.co.uk
> 	1957747793 lrw-r--r--  1 agc  agc          9 Nov  9 17:55 ip -> 10.4.0.42
> 	1649760492 lrw-r--r--  1 agc  agc         16 Nov  9 17:55 product -> NetBSD iSCSI
> 	1681692777 -rw-r--r--  1 agc  agc  104857088 Nov  9 17:55 storage
> 	 424238335 lrw-r--r--  1 agc  agc         43 Nov  9 17:55 targetname -> iqn.1994-04.org.netbsd.iscsi-target:target0
> 	 719885386 lrw-r--r--  1 agc  agc          8 Nov  9 17:55 vendor -> NetBSD
> 	 596516649 lrw-r--r--  1 agc  agc          4 Nov  9 17:55 version -> 0
> 	[9:27:09] agc@inspiron1300 ...examples/refuse/iscsi-initiator 434 >

What do you mean ls can't find files?  You have just quoted an example
where ls does find files unless I misreading it somehow?

Also, e.g. vnconfig does not use fts.  So looks like lookup is failing.
But it seems to be succeeding for the case you quoted.  So I'm a bit
puzzled and think ino number masking is only hiding some real bug.

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"