Mail Archives: cygwin/2006/02/12/01:25:46
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/
- Raw text -