[patch] (win32) extremely slow opening files on network shares

[David Anderson]

Hi,

MSDN states:

________________________________________
You cannot use root directories as the lpFileName input string for FindFirstFile—with or without a trailing backslash. If you want to see files or get the attributes of a root directory, do the following:
• To see files in a root directory, you can use "C:\*" and step through the directory by using FindNextFile.
• To get the attributes of a root directory, use GetFileAttributes.
Note  Prepending the string "\\?\" does not allow access to the root directory.
On network shares, you can use an lpFileName in the form of the following: "\\server\service\*" but you cannot use an lpFileName that points to the share itself, for example, "\\server\service".
________________________________________

Solution: append ‘\*’ to the search string if the searching a directory, server, or network share.

-David Anderson

diff -r 073ff46fe397 src/os_win32.c
--- a/src/os_win32.c Fri Aug 20 11:11:57 2010 +0200
+++ b/src/os_win32.c Mon Aug 23 19:27:56 2010 -0400
@@ -2273,6 +2273,7 @@
     int len)
{
     char szTrueName[_MAX_PATH + 2];
+    char szTrueNameTemp[_MAX_PATH + 2];
     char *ptrue, *ptruePrev;
     char *porig, *porigPrev;
     int flen;
@@ -2324,11 +2325,22 @@
*ptrue = NUL;

/* Skip "", "." and "..". */
+        {
+            int slen;
+            STRCPY( szTrueNameTemp, szTrueName );
+            slen = strlen( szTrueNameTemp );
+            if( *porig == psepc && slen + 2 < _MAX_PATH ) {
+                szTrueNameTemp[slen+0] = '\\';
+                szTrueNameTemp[slen+1] = '*';
+                szTrueNameTemp[slen+2] = 0;
+            }
+        }
+
if (ptrue > ptruePrev
&& (ptruePrev[0] != '.'
     || (ptruePrev[1] != NUL
&& (ptruePrev[1] != '.' || ptruePrev[2] != NUL)))
- && (hFind = FindFirstFile(szTrueName, &fb))
+ && (hFind = FindFirstFile(szTrueNameTemp, &fb))
       != INVALID_HANDLE_VALUE)
{
     c = *porig;

[John Beckett]

David Anderson wrote:
> Subject: [patch] (win32) extremely slow opening files on
> network shares

This is a very important patch because we have had many Windows
users report extremely slow access to files over a network. I
have edited David's patch by including a comment about its
purpose, and to use Vim source style. See attached file which I
believe is equivalent to David's patch. I have compiled and
given a VERY quick test (really no testing at all because I have
to go and I wanted to post this).

David Anderson's explanation is:

MSDN states (edited):

You cannot use root directories as the lpFileName input string for

FindFirstFile -- with or without a trailing backslash.

If you want to see files or get the attributes of a root directory,
do the following:

- To see files in a root directory, you can use "C:\*" and

step through the directory by using FindNextFile.

- To get the attributes of a root directory, use GetFileAttributes.
On network shares, you can use an lpFileName like:

"\\server\service\*" but you cannot use an lpFileName that points
to the share itself, for example, "\\server\service".

David's patch appends '\*' to the search string if searching a

directory, server, or network share.

John

[Will Rogers]

This is an important patch. I have been very frustrated in my work the
past couple weeks because opening any file on the network in Vim took
forever. I just applied John Beckett's version of the patch to the
7.3.019 sources from Mercurial, and it fixed the problem. Thank you
for posting the patch, and please consider applying it to the official
Vim source.


-- Will

[John Beckett]

I don't work in such a way that I encounter the problem, but I
tried fiddling around with a quick test and could not reproduce
it.

Can you spell out a situation which reliably shows the problem?
Do you know the exact conditions of starting Vim which
demonstrate the issue?

Using "open" from Windows Explorer in a network share?

At command prompt, one or both of these?:
gvim x:\file.txt
gvim \\server\share\file.txt

where x: is a mapped network drive?

Or is it within Vim when you do something like:
:e x:\file.txt

Exactly what happens (always get delay of roughly how long?
only sometimes?).

John