This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[octave ] LOADPATH recurses only one level of subdirectories (on network drives)


So the punch line is that octave will not work with network drives due to the difference on how "stat" returns the number of hard links. Octave uses stat to determine if the directory is recusible. But you can replicate the problem with using stat on the command line.

$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

The code checks for two links (the %h) given that a subdirectory should have a "." and a ".." entry. But for some reason, network drives created using windows within cygwin report 1.

So I'm at the edge of my understanding - should cygwin be reporting 2 or 1 or is octave using a method that works on every other system except cygwin.

Larrie.

Larrie Carr wrote
John W. Eaton wrote
Probably the code you are looking for is the function do_subdir in
liboctave/kpse.cc.  This file contains a stripped-down version of the
kpathsearch library.  Most modifications were to remove TeX-specific
stuff and to convert it to use std::string instead of plain C strings
which historically leaked memory.  In any case, that function may use
an optimization to decide when to check for subdirectories.  The
optimization looks at the link count of the current directory.  If it
is 2, then the assumption is that the current directory does not
contain any subdirectories.  That seems to work fine for Unixy
systems.  Does that assumption not hold for Cygwin?  If so, then I
think the fix is fairly simple as there is also Windows-specific code
in that function.  Whether the optimization is performed depends on
what is #defined at compile time, so you'll probably have to do some
checking on a Cygwin system to see what is really going on.


Well, after some more experimenting, the problem appears related to using the recursive search feature of LOADPATH on a *network* drive. That is,

If the path is located within a physically attached hard drive, octave operates as expected. For instance, /cygdrive/c/test// works all the way down to /cygdrive/c/test/a/b/c/d/e/

If the path is located on a network drive created using windows "Map Network Drive" menu option under "My Computer", octave will only recurse down 1 level of subdirectory. For instance "/usr/share/octave/site/m// does not work.

And if I use a cygwin windows mapping instead "/cygdrive/x/cygwin/usr/share/octave/site/m//, it still does not work correctly and recurses down only one level.

In my installation, the entire cygwin root is located on a network drive (and no one else uses it). Works just fine for everything else.

John, it you got any other hints, I would appreciate it as I'm diving in.

Larrie.





-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]