3.1.2 beta bug

3.1.2 beta bug

[Jesse Zbikowski]

Hello,

I am experiencing the following anomaly from zsh 3.1.2 running under
IRIX: filename glob patterns which encompass multiple directories fail to
generate any filenames on the IRIX hwfgs filesystem.  This is the
filesystem which maps hardware devices to files and directories; there
is no such problem on the "normal" xfs filesystem.

[pizza]11:46AM@/>uname -a
IRIX64 pizza 6.4 02121744 IP27
[pizza]11:47AM@/>echo $ZSH_VERSION
3.0.4
[pizza]11:47AM@/>echo /hw/a*
/hw/atm /hw/audio
[pizza]11:47AM@/>echo /hw/a*/*
/hw/atm/0 /hw/atm/1 /hw/atm/2 /hw/atm/3 /hw/audio/RAD1
[pizza]11:48AM@/>exec zsh-3.1.2
[pizza]11:48AM@/>echo $ZSH_VERSION
3.1.2
[pizza]11:48AM@/>echo /hw/a*
/hw/atm /hw/audio
[pizza]11:48AM@/>echo /hw/a*/*
zsh: no matches found: /hw/a*/*
[pizza]11:48AM@/[1]>df /hw
Filesystem             Type  blocks     use     avail  %use Mounted on
/hw                   hwgfs        0        0        0   0  /hw

--
Jesse Zbikowski				Digital Video Engineer
jdz@engr.sgi.com			SGI Advanced Entertainment Systems

Re: 3.1.2 beta bug

[Zoltan Hidvegi]

> I am experiencing the following anomaly from zsh 3.1.2 running under
> IRIX: filename glob patterns which encompass multiple directories fail to
> generate any filenames on the IRIX hwfgs filesystem.  This is the
> filesystem which maps hardware devices to files and directories; there
> is no such problem on the "normal" xfs filesystem.

As an experiment, 3.1.2 has leaf optimization.  It is assumed that a
directory has no subdirectories if a directory has a link count less than
2.  This optimization is also used by GNU find as I know.  Too bad that
it does not work, since it can speed up some searches a lot (especially
**/file type pattern globs).  Maybe a test for nlink == 2 instead of <= 2
would help.  A filesystem without the usual Unix directory link count
semantics would probably have link count 1 for directories.

Try this patch.

Zoltan


--- glob.c	1997/06/02 04:19:48	3.1.2.2
+++ glob.c	1997/07/21 19:46:42
@@ -364,7 +364,7 @@
 	    struct stat st;
 	    stat(fn, &st);
 	    /* a directory with subdirectories has link count greater than 2 */
-	    if (!S_ISDIR(st.st_mode) || st.st_nlink <= 2)
+	    if (!S_ISDIR(st.st_mode) || st.st_nlink == 2)
 		return;
 	}
 	lock = opendir(fn);

Re: 3.1.2 beta bug

[Andrew Main]

Zoltan Hidvegi wrote:
>As an experiment, 3.1.2 has leaf optimization.  It is assumed that a
>directory has no subdirectories if a directory has a link count less than
>2.  This optimization is also used by GNU find as I know.  Too bad that
>it does not work, since it can speed up some searches a lot (especially
>**/file type pattern globs).

find has an option "-noleaf" to disable the optimisation.  Perhaps we
need a similar option in zsh?

>                              Maybe a test for nlink == 2 instead of <= 2
>would help.  A filesystem without the usual Unix directory link count
>semantics would probably have link count 1 for directories.

No, not really.  Under Linux:

% ls -ld /proc /proc/*(/)
dr-xr-xr-x   5 root     root            0 Apr 30 22:29 /proc
dr-xr-xr-x   3 root     root            0 Jul 22 09:27 /proc/1
dr-xr-xr-x   3 root     root            0 Jul 22 09:27 /proc/11688
dr-xr-xr-x   3 root     root            0 Jul 22 09:27 /proc/12
dr-xr-xr-x   3 root     root            0 Jul 22 09:27 /proc/13
[many other processes]
dr-xr-xr-x   2 root     root            0 Jul 22 08:44 /proc/net
dr-xr-xr-x   2 root     root            0 Jul 22 09:27 /proc/scsi
dr-xr-xr-x   5 root     root            0 Jul 22 09:27 /proc/sys

The link count of 5 on /proc suggests three subdirectories, whereas it
actually has many more.  Even if zsh isn't doing that form of leaf
optimisation, the fact remains that a directory can easily have a
meaningful but wrong link count.  Not to mention the possibility of
a directory actually having multiple links other than . and .. (more
useful than one might imagine).

Leaf optimisation, though powerful, is of use in such limited
circumstances that it is almost useless.

-zefram

Re: 3.1.2 beta bug

[Geoff Wing]

Andrew Main <zefram@tao.co.uk> typed:
:Zoltan Hidvegi wrote:
:>                              Maybe a test for nlink == 2 instead of <= 2
:>would help.  A filesystem without the usual Unix directory link count
:>semantics would probably have link count 1 for directories.

Hmm, under MSDOS FAT FS on NetBSD, all directories reckon they are 1.
Given the limitations of the file-system, it probably will never be better.

% ls -ld /msdos/WIN95/
drwxr-x---  1 root  master  16384 Jun 25 07:20 /msdos/WIN95/
-- 
Geoff Wing [mason@primenet.com.au]                   Phone    : +61-3-9818 2977 
 Technical Manager: PrimeNet Computer Consultants    Facsimile: +61-3-9819 3788 
 Web: <URL:http://www.primenet.com.au/>              Mobile   : 0412 162 441
 

Re: 3.1.2 beta bug

[Zoltan T. Hidvegi]

Andrew Main wrote:
> >                              Maybe a test for nlink == 2 instead of <= 2
> >would help.  A filesystem without the usual Unix directory link count
> >semantics would probably have link count 1 for directories.
>
> No, not really.  Under Linux:
>
> % ls -ld /proc /proc/*(/)
> dr-xr-xr-x   5 root     root            0 Apr 30 22:29 /proc
[...]
> The link count of 5 on /proc suggests three subdirectories, whereas it
> actually has many more.  Even if zsh isn't doing that form of leaf
> optimisation, the fact remains that a directory can easily have a
> meaningful but wrong link count.  Not to mention the possibility of
> a directory actually having multiple links other than . and .. (more
> useful than one might imagine).

Zsh only uses a vesimple leaf optimization.  The only assumption it makes
(after my last patch) is that a directory with link count 2 has no
subdirectories.  It does not assume that a directory with more than 2 links
has any subdirectories or has at most nlink-2 subdirs.  And that assumption
is corrent in almost all cases.  I know of no filesystem on Linux where
this assumption fails.  The msdos filesystem for example corretly emulates
the Unix semantics.  But certainly there should be a configure option for
this.  The question is the default state of this option.  It can even be a
runtime option, as really the extra code is just one test.  And with that
run-time option enabled we may even do full leaf optimization.  The
reporter of the original problem from SGI still haven't answered, I'd like
to know if this assumption holds for this funny SGI filesystem.

Zoltan