Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-Injected-Via-Gmane:	http://gmane.org/
To:	cygwin AT cygwin DOT com
From:	Rolf Campbell <rcampbell AT tropicnetworks DOT com>
Subject:	Re: (1.3.22) mount: strange 15 second delay
Date:	Fri, 18 Apr 2003 18:37:10 -0400
Lines:	59
Message-ID:	<b7pul6$ucb$1@main.gmane.org>
References:	<b7ndcb$1pq$1 AT main DOT gmane DOT org> <20030418001208 DOT GC18611 AT redhat DOT com> <b7npqn$ecj$1 AT main DOT gmane DOT org>
Reply-To:	IDontLikePersonalReplies AT hotmail DOT com
Mime-Version:	1.0
X-Complaints-To:	usenet AT main DOT gmane DOT org
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
X-Accept-Language:	en-us, en
In-Reply-To:	<b7npqn$ecj$1@main.gmane.org>

Rolf Campbell wrote:
> Ok, I recompiled the mount.exe program with -ggdb.  The delay was in on 
> line 382.  The last call to getmntent (the one that returns NULL) is the 
> one that takes > 10 seconds.
> 
> Was hoping that this would spark a thought in someone.  I'll start 
> trying to get a debug cygwin load building to test further.
> 
> 374:static void
> 375:show_mounts (void)
> 376:{
> 377:  FILE *m = setmntent ("/-not-used-", "r");
> 378:  struct mntent *p;
> 379:  const char *format = "%s on %s type %s (%s)\n";
> 380:
> 381:  // printf (format, "Device", "Directory", "Type", "Flags");
> 382:  while ((p = getmntent (m)) != NULL)
> 383:    printf (format, p->mnt_fsname, p->mnt_dir, p->mnt_type, 
> p->mnt_opts);
> 384:  endmntent (m);
> 385:}

Now I got the dll building on my machine.  And I know what the real 
problem is.  If a network mounted drive is innaccesible for whatever 
reason, GetFileAttributes("i:\\") will take a LONG time.  So, I just 
avoided running that command on "REMOTE" drives.

So, here's a patch:

Index: path.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/path.cc,v
retrieving revision 1.248
diff -u -p -r1.248 path.cc
--- path.cc	9 Mar 2003 20:31:07 -0000	1.248
+++ path.cc	18 Apr 2003 22:29:48 -0000
@@ -2423,8 +2423,13 @@ cygdrive_getmntent ()
  	  break;

        __small_sprintf (native_path, "%c:\\", drive);
-      if (GetDriveType (native_path) == DRIVE_REMOVABLE ||
-	  GetFileAttributes (native_path) == INVALID_FILE_ATTRIBUTES)
+      unsigned driveType = GetDriveType(native_path);
+
+      if (driveType != DRIVE_REMOTE &&
+          //Remote drives are always valid (takes too long to really
+          // validate.
+          (driveType == DRIVE_REMOVABLE ||
+           GetFileAttributes(native_path) == INVALID_FILE_ATTRIBUTES))
  	{
  	  available_drives &= ~mask;
  	  continue;


And changelog entry:
2003-04-18  Rolf Campbell  <Endlisnis AT mailc DOT net>

	* path.cc (driveType): Don't call GetFileAttributes on REMOTE drives.



--
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 -