Re: octave does not recurse LOADPATH directories located on the network in cygwin

[James R. Phillips]

--- Larrie Carr  wrote:

> So I manually applied this patch as kspe.cc and did appear to work as 
> advertised.  Both network and non-network drives now search properly.  But 
> my build is a little weak as this is not my area of expertise and I'm not 
> using all the same version numbers as CYGWIN-PATCHES lists.
> 
> James, could you please release a 2.1.72-2 build with this patch as a 
> production release?  Big thanks if you do.
> 
> Thanks again.
> Larrie.
> 
> ----- Original Message ----- 
> From: "John W. Eaton"
> 
> > | In a cygwin environment, octave does not recursively search through 
> > LOADPATH
> > | directories if the directories are located on network drives.
> > |
> > | The problem is due to the use of stat() to calculate link_num in 
> > dir_link()
> > | in kpse.cc.  In a cygwin environment, stat() always reports 1 for a
> > | directory located on a network drive.  A test case using stat on the 
> > command
> > | line where the root of cygwin is stored on a network drive (x: in this
> > | case).
> > |
> > | $stat -c "%h %f" /cygdrive/c/test
> > | 2 41c0
> > |
> > | $stat -c "%h %f" /usr/share/octave
> > | 1 41ed
> > |
> > | $stat -c "%h %f" /cygdrive/x/cygwin/usr/share/octave
> > | 1 41ed
> > |
> > | $ls -l /usr/share/octave
> > | total 0
> > | drwxr-xr-x 1 larrie mkpasswd 0 Feb   8 23.31 2.1.72
> > | drwxr-xr-x 1 larrie mkpasswd 0 Feb   8 23.31 site
> > |
> > | Looking at 2.1.72,  The code within do_subdir() does not handle 1 as a
> > | subdirectory as it
> > | expects a non-empty subdirectory is >2.
> > |
> > | I don't know why cygwin only reports 1 for a network drive, except other
> > | people have seen this.  For instance, perl on cygwin,
> > |
> > | http://www.scit.wlv.ac.uk/~jphb/perl/pod/perlcygwin.html
> > | Hard Links
> > | FAT partitions do not support hard links (whereas NTFS does), in which 
> > case
> > | Cygwin implements link() by copying the file. On remote (network) drives
> > | Cygwin's stat() always sets st_nlink to 1, so the link count for remote
> > | directories and files is not available. In either case, these tests will
> > | fail:
> > |
> > |   Failed Test           List of failed
> > |   ------------------------------------
> > |   io/fs.t               4
> > |   op/stat.t             3
> > |
> > | However, stat() always correctly identifies the path as a directory.   I
> > | guess a fix would be to remove the optimization so that every 
> > subdirectory
> > | is recursed into and then handle the "." cases as before to allow empty
> > | directories to work as before.
> >
> > Please try the following patch.  The intent is to turn off the special
> > link count trick for Cygwin systems.  A better solution might be to
> > only skip the link count trick on network drives, but I don't know how
> > to check for that, so someone else will have to provide a patch.  If
> > you'd like to try to implement that, search for ST_NLINK_TRICK in
> > liboctve/kpse.cc to see where and how it is used (there is only one
> > fuction where it appears).
> >
> > jwe
> >
> >
> > liboctave/ChangeLog:
> >
> > 2006-02-13  John W. Eaton  <address@hidden>
> >
> > * kpse.cc: Don't define ST_NLINK_TRICK for Cygwin systems.
> >
> >
> > Index: liboctave/kpse.cc
> > ===================================================================
> > RCS file: /cvs/octave/liboctave/kpse.cc,v
> > retrieving revision 1.27
> > diff -u -r1.27 kpse.cc
> > --- liboctave/kpse.cc 13 Feb 2006 17:21:31 -0000 1.27
> > +++ liboctave/kpse.cc 13 Feb 2006 18:17:36 -0000
> > @@ -73,8 +73,9 @@
> >
> > /* If you want to find subdirectories in a directory with non-Unix
> >    semantics (specifically, if a directory with no subdirectories does
> > -   not have exactly two links), define this.  */
> > -#if !defined (DOSISH) || defined(__DJGPP__)
> > +   not have exactly two links), define this.  Cygwin systems do not
> > +   have Unix semantics for network mapped drives.  */
> > +#if defined(__DJGPP__) || ! (defined (DOSISH) || defined (__CYGWIN__))
> > /* Surprise!  DJGPP returns st_nlink exactly like on Unix.  */
> > #define ST_NLINK_TRICK
> > #endif /* either not DOSISH or __DJGPP__ */
> > 
> 

I'm not opposed in principle, but I may not get to it for a while.

Are there any significant performance downsides to the patch?

jrp