From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14808 invoked by alias); 12 Feb 2006 06:25:34 -0000 Received: (qmail 14800 invoked by uid 22791); 12 Feb 2006 06:25:34 -0000 X-Spam-Check-By: sourceware.org Received: from outbound01.telus.net (HELO priv-edtnes57.telusplanet.net) (199.185.220.220) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 12 Feb 2006 06:25:32 +0000 Received: from homelarrie ([207.81.250.27]) by priv-edtnes57.telusplanet.net (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with SMTP id <20060212062530.VAHE10261.priv-edtnes57.telusplanet.net@homelarrie>; Sat, 11 Feb 2006 23:25:30 -0700 Message-ID: <03ed01c62f9d$1aff55b0$0201a8c0@homelarrie> From: "Larrie Carr" To: "Larrie Carr" , "John W. Eaton" Cc: References: <017b01c62daf$7696d140$0201a8c0@homelarrie> <17387.42303.91508.260685@segfault.lan> <01a501c62dba$18fc1b20$0201a8c0@homelarrie> <029001c62ebf$032b7a10$0201a8c0@homelarrie> Subject: [octave ] LOADPATH recurses only one level of subdirectories (on network drives) Date: Sun, 12 Feb 2006 08:44:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2006-02/txt/msg00423.txt.bz2 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/