vim slow with UNC paths

[Hugo Ahlenius]

Hi,

I have experienced an issue for quite some time, and now I finally
decided to deal with it - vim gets painfully slow accessing files
using UNC paths on Windows (paths that look like \\server\share\folder
\file). I have tested with Windows XP and Vista on several machines.
Using an old fashioned drive letter goes about x20 times faster -
otherwise vim freezes for long periods: 10-20 secs.

I have tested with both vim 7.1 and 7.2 (including gvim, and both 32-
bit and 64-bit vim). I have tried without any customizations loaded,
and without swap-files, but no change.

I can see that a few other people have seen the same problem, and that
there might be a fix/workaround in Cream (I tried to peek in the files
there, but couldn't find anything...)

http://markmail.org/message/4d2wi7q6m3zgmszg#query:+page:1+mid:3425grt6sqtxxdrw+state:results

http://www.archivum.info/comp.editors/2007-07/msg00053.html

http://groups.google.com/group/vim_use/browse_thread/thread/307397da9c540bec/69fc832b7ef632d1?lnk=gst&q=unc#69fc832b7ef632d1
http://www.mail-archive.com/vim...@googlegroups.com/msg01771.html

Any tips on how to solve this?

[Tony Mechelynck]

The slowness might be due to something outside of Vim.

Reading C:\Program Files\vim\vim72\vimrc_example.vim goes much faster
than reading ftp://ftp.vim.org/pub/vim/patches/7.2/README because the
former is on your computer and can be read extremely fast, the latter
must be transmitted over a network with limited speed and an additional
overhead to establish the connection. Even if the server is on your own
computer, getting a file via a server involves much more overhead
(before the first byte of the file can be read) than reading a file
directly in C:\path\to\filename.ext format your hard disk.

In addition, if Vim is set to put its swapfile in the same directory as
the editfile (which is the usual default when that directory is
writable), there is additional overhead if that file is at a remote
location. In that case, see the 'swapfile' and 'directory' options about
how to suppress using a swapfile for a given buffer, or placing the
swapfile at a different (faster-accessed) location.

Best regards,
Tony.
--
ARTHUR: Bloody peasant!
DENNIS: Oh, what a give away. Did you hear that, did you hear that, eh?
That's what I'm on about -- did you see him repressing me, you
saw it
didn't you?
The Quest for the Holy Grail (Monty
Python)

[John Beckett]

Hugo Ahlenius wrote:
> I have experienced an issue for quite some time, and now I
> finally decided to deal with it - vim gets painfully slow
> accessing files using UNC paths on Windows (paths that look
> like \\server\share\folder \file). I have tested with Windows
> XP and Vista on several machines.

I don't use Vim like that, so haven't encountered the issue. Some random
thoughts follow.

First, I have seen issues about slow access to UNC paths years ago
(nothing to do with Vim). There was some well-known issue about network
provider order which was particularly apparent when people had enabled
the Microsoft software to allow access to NetWare servers. Also, the
first access can be slow due to a need for network authentication after
the server has timed-out the client. However, you are probably not
seeing these.

In Vim's source code, we find function fname_case() in file os_win32.c.
I have noticed that function has an amazing trick. When you provide a
file path name to Vim (on Windows), Vim wants to determine the correct
case (the "true name") for each component of the path. Irritatingly,
Windows provides no assistance, so Vim has to start from the root and
search for the first directory in the root to determine its true name.
That is repeated for each component of the path.

I haven't looked to see what happens with a UNC path, but Vim might use
FindFirstFile on the \\server and/or the \\server\share components (as
well as on following directory components). That might cause various
timeouts, or certainly a slowdown.

I mention all this in the hope that someone is inspired to do a bit of
testing.

John

[Tony Mechelynck]

I think I saw somewhere in the help that on Dos/Windows, Vim treats a
double backslash in a filename as identical to a single backslash;
however I cannot find it back

Best regards,
Tony.
--
ARTHUR: You fight with the strength of many men, Sir knight.
I am Arthur, King of the Britons. [pause]
I seek the finest and the bravest knights in the land to join me
in my Court of Camelot. [pause]
You have proved yourself worthy; will you join me? [pause]
You make me sad. So be it. Come, Patsy.
BLACK KNIGHT: None shall pass.

[Hugo Ahlenius]

| Reading C:\Program Files\vim\vim72\vimrc_example.vim goes much faster
| than reading ftp://ftp.vim.org/pub/vim/patches/7.2/README because the
| former is on your computer and can be read extremely fast, the latter
| must be transmitted over a network with limited speed and an
| additional overhead to establish the connection. Even if the server is
| on your own computer, getting a file via a server involves much more
| overhead (before the first byte of the file can be read) than reading
| a file directly in C:\path\to\filename.ext format your hard disk.
| In addition, if Vim is set to put its swapfile in the same directory
| as the editfile (which is the usual default when that directory is
| writable), there is additional overhead if that file is at a remote
| location. In that case, see the 'swapfile' and 'directory' options
| about how to suppress using a swapfile for a given buffer, or placing
| the swapfile at a different (faster-accessed) location.

Tony,
I have eliminated other issues and isolated that it is in vim. I have tested
without swapfile, and it gives the same pattern, and the same file is
accessed fast in any method on e.g. notepad or using type.exe - and is
loaded fast in vim if accessed with a drive letter rather than a UNC path...

So it is very likely that it is something related to the leading double
slashes.

/H.

[Ben Fritz]

On Jan 7, 4:22 pm, Tony Mechelynck <antoine.mechely...@gmail.com>
wrote:

> Reading C:\Program Files\vim\vim72\vimrc_example.vim goes much faster

> than readingftp://ftp.vim.org/pub/vim/patches/7.2/READMEbecause the

> former is on your computer and can be read extremely fast, the latter
> must be transmitted over a network with limited speed and an additional
> overhead to establish the connection. Even if the server is on your own
> computer, getting a file via a server involves much more overhead
> (before the first byte of the file can be read) than reading a file
> directly in C:\path\to\filename.ext format your hard disk.
>

I think, that when Hugo mentions "old fashioned drive letters" vs UNC
paths, he is referring to a "mapped network drive" as Windows calls
it, which is just a shortcut to a UNC path.

If I understand correctly, Hugo is noticing a speed difference
accessing the _same_ file using two different methods. For example, if
you have a "U:" drive mapped to "\\server\userspace\username", and try
to access U:\example.txt, it will be much faster than accessing \
\server\userspace\username\example.txt.

Please correct me if I'm misrepresenting your problem, Hugo.

Unfortunately, I cannot say that I've noticed this problem, nor do I
really understand networking in Windows very well, so I won't be of
much help.

[Hugo Ahlenius]

| I think, that when Hugo mentions "old fashioned drive letters" vs UNC
| paths, he is referring to a "mapped network drive" as Windows calls
| it, which is just a shortcut to a UNC path.
| If I understand correctly, Hugo is noticing a speed difference
| accessing the _same_ file using two different methods. For example, if
| you have a "U:" drive mapped to "\\server\userspace\username", and try
| to access U:\example.txt, it will be much faster than accessing \
| \server\userspace\username\example.txt.

Ben, you are understanding it correctly. I see that some installer has left
a small 88 byte "log.txt" file in the root of my hard drive. Accessing it
through c:\log.txt is fast, accessing it through \\computer\c$\log.txt is
very slow (locks up gvim for 20 secs).

| Unfortunately, I cannot say that I've noticed this problem, nor do I
| really understand networking in Windows very well, so I won't be of
| much help.

Well, it would be helpful if other Windows user could confirm that this
problem exist, or identify if it could be related to my setup(s).

:)

Cheers,
Hugo

[Matthias Müller]

Hallo,

Am Donnerstag, 8. Januar 2009 20:42 schrieb Hugo Ahlenius:
snip

> Well, it would be helpful if other Windows user could confirm that this
> problem exist, or identify if it could be related to my setup(s).

I can confirm this problem.

I am working with gvim on an WinXP machine. The files I'm working with are
stored at a directory that is originally located on an AIX (IBMs Unix
flavour) machine. Access to the files is via Samba Version 3.0.28.
When I open the files like \\server\share\file.txt it takes longer (I guess 7
to 8 times) than I open the file after I mapped a driveletter with eg "net
use l: \\server\share"

I thought this is a problem cause either Windows remembers every network
connection including the broken one and waits for some timeouts or the number
of files is about several thousand in some other shares and WinExplorer
collects all of the file names.

--
Mit freundlichen Grüßen
Matthias Müller
(Benutzer #439779 im Linux-Counter http://counter.li.org)
PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten!
Siehe auch: http://www.gnu.org/philosophy/no-word-attachments.de.html

[bill lam]

Not exactly the same problem but might be related. When try to access
a file on lan using \\foo\bar\.. it just timeout and said cannot
connect. It needs first using file explorer or network neighbour to
open that folder, then the file can be open from application.
Alternatively using IP instead of server name (such as
\\192.168.1.123\bar) can also solve the problem.

It seems related to the netbuei (or it got a newer name I cannot
remember), a computer has to broadcast message over the lan to find
out where is the computer which acts as the primary controller, if
there is none, the computers will elect another one as the primary
controller.

--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩215 李商隱 無題
相見時難別亦難 東風無力百花殘 春蠶到死絲方盡 蠟炬成灰淚始乾
曉鏡但愁雲鬢改 夜吟應覺月光寒 蓬萊此去無多路 青鳥殷勤為探看

[John Beckett]

Hugo Ahlenius wrote:
> Accessing it through c:\log.txt is fast,
> accessing it through \\computer\c$\log.txt is very slow
> (locks up gvim for 20 secs).

I was going to try over a network, but I thought I'd start with the
above. On
an XP computer, with a user in the Administrators group, I executed
command
(console Vim 7.2):

vim \\computer\c$\test.txt

replacing 'computer' with the name of the computer, and where file
C:\test.txt
exists (130 bytes), and c$ is the default administrative share for C:\.

Result: File displayed immediately (under half-second delay).

If you don't get the same, I suppose I won't bother with more elaborate
testing. We are now off-topic for Vim, but you should check what network
protocols you have installed, and how name resolution is configured.
Assuming
TCP/IP only, it's a bit perplexing because the system is supposed to
recognise
its own name as the first step. Perhaps look in the System log in Event
Viewer
and see if there are any complaints (errors since the last start). I
wonder if
some anti-virus software is giving trouble.

What is time taken for each of:
vim \\computer\c$\test.txt
notepad \\computer\c$\test.txt

John

[BC]

On Wed, Jan 7, 2009 at 10:06 PM, Tony Mechelynck
<antoine.m...@gmail.com> wrote:
>
> I think I saw somewhere in the help that on Dos/Windows, Vim treats a
> double backslash in a filename as identical to a single backslash;
> however I cannot find it back
>

Yes.
:help dos-backslash

2. Using backslashes *dos-backslash*

Using backslashes in file names can be a problem. Vi halves the number of
backslashes for some commands. Vim is a bit more tolerant and does not remove
backslashes from a file name, so ":e c:\foo\bar" works as expected. But when
a backslash occurs before a special character (space, comma, backslash, etc.),
Vim removes the backslash. Use slashes to avoid problems: ":e c:/foo/bar"
works fine. Vim replaces the slashes with backslashes internally to avoid
problems with some MS-DOS programs and Win32 programs.

When you prefer to use forward slashes, set the 'shellslash' option. Vim will
then replace backslashes with forward slashes when expanding file names. This
is especially useful when using a Unix-like 'shell'.

So, I presume \\\ would be treated as equivalent to \\ ???

[Hugo Ahlenius]

| vim \\computer\c$\test.txt
| notepad \\computer\c$\test.txt

Thanks everyone for input and comments. Using e.g. type.exe or notepad.exe
is nearly instant, only vim is slow, so I am pretty sure it is vim related.
Interesting is also that tab-completion of a filename on the :e prompt is
fast, just the opening (and writing) is slow.

But... I tried setting "shellslash" now, as suggested by BC - and that does
it - then \\computer\c$\test.txt works, being translated as
//computer/c$/test.txt

With noshellslash (defaults) //computer/c$/test.txt is fast.

I would prefer to have windows/dos directory slashes, but I guess I could
live with shellslash... !

Since a few other people (Matthias Müller for one) are seeing the same
problem, could this maybe be logged as a bug... ?

Thanks everyone!

/Hugo

[Tony Mechelynck]

On 09/01/09 09:01, Hugo Ahlenius wrote:
> | vim \\computer\c$\test.txt
> | notepad \\computer\c$\test.txt
>
> Thanks everyone for input and comments. Using e.g. type.exe or notepad.exe
> is nearly instant, only vim is slow, so I am pretty sure it is vim related.
> Interesting is also that tab-completion of a filename on the :e prompt is
> fast, just the opening (and writing) is slow.
>
> But... I tried setting "shellslash" now, as suggested by BC - and that does
> it - then \\computer\c$\test.txt works, being translated as
> //computer/c$/test.txt
>
> With noshellslash (defaults) //computer/c$/test.txt is fast.

I guess the above is the way to do it. Forward slashes is the Vim
default; they are normally (i.e. with 'noshellslash', an option defined
only on Dos/Windows/OS2) translated to backslashes when passing a path
to a Dos-like shell.

>
> I would prefer to have windows/dos directory slashes, but I guess I could
> live with shellslash... !
>
> Since a few other people (Matthias Müller for one) are seeing the same
> problem, could this maybe be logged as a bug... ?

I'd call a feature (or a limitation depending on point of view), not a
bug. A feature because it means you can use forward slashes
cross-platform in Vim, an portability advantage for people who go
regularly from one platform to another. Working as portably as possible
on various platforms has always been one of the strong points of Vim.
Also an advantage for people who, like me, need an AltGr keychord to
type a backslash, hitting two keys simultaneously at opposite ends of
their national keyboard, but only a shift-chord, which can easily be
done with only the right hand, in order to type a forward slash.

>
> Thanks everyone!
>
> /Hugo

Best regards,
Tony.
--
"If just one piece of mail gets lost, well, they'll just think they
forgot to send it. But if *two* pieces of mail get lost, hell, they'll
just think the other guy hasn't gotten around to answering his mail.
And if *fifty* pieces of mail get lost, can you imagine it, if *fifty*
pieces of mail get lost, why they'll think someone *else* is broken!
And if 1Gb of mail gets lost, they'll just *know* that Arpa is down and
think it's a conspiracy to keep them from their God given right to
receive Net Mail ..."
-- Leith (Casey) Leedom

[BC]

On Fri, Jan 9, 2009 at 3:01 AM, Hugo Ahlenius wrote:
>

> But... I tried setting "shellslash" now, as suggested by BC - and that does
> it - then \\computer\c$\test.txt works, being translated as
> //computer/c$/test.txt
>

I wish I had thought to suggest it - but I was just quoting from the
help -- and I was too clueless to format the post so the quoted text
didn't look like my own. Tony's comment jogged my memory regarding the
treatment of backslashes before special characters. (Not that I
understand these issues at all. I have plenty of questions of my own
regarding paths that I need help with when I can formulate my
questions clearly...)

I was also clueless enough, despite having read the threads regarding
posting people's email addresses! - to have let an address slip into
my post. Sorry!

[Hugo Ahlenius]

|From: vim...@googlegroups.com
|[mailto:vim...@googlegroups.com] On Behalf Of Tony Mechelynck

|> I would prefer to have windows/dos directory slashes, but I
|guess I could
|> live with shellslash... !

|I'd call a feature (or a limitation depending on point of view), not a
|bug. A feature because it means you can use forward slashes
|cross-platform in Vim, an portability advantage for people who go
|regularly from one platform to another. Working as portably as
|possible
|on various platforms has always been one of the strong points of Vim.
|Also an advantage for people who, like me, need an AltGr keychord to
|type a backslash, hitting two keys simultaneously at opposite ends of
|their national keyboard, but only a shift-chord, which can easily be
|done with only the right hand, in order to type a forward slash.

Tony, I see your point, but isn't the feature to have backward-slashes
broken, if the implementation stumbles on network paths - and I doubt that
it would be so hard to fix it...

/H.

[Tony Mechelynck]

I saw that //server/share/folder/filename.ext (with foeward
slashes)worked OK, even on Windows. Wasn't it in one of your posts? So
the implementation doesn't stumble on network paths, if you know how to
type them. And I said you could call it a limitation.

Best regards,
Tony.
--
CAPRICORN (Dec 23 - Jan 19)
You are conservative and afraid of taking risks. You don't do
much of anything and are lazy. There has never been a Capricorn of any
importance. Capricorns should avoid standing still for too long as
they take root and become trees.

[Hugo Ahlenius]

I think I may have to resurrect this old thread... Don't know what has
happened, but the problem has re-surfaced on my Vista 64-bit laptop -
and shellslash doesn't help, and having // slashes doesn't help.

And I have no idea what could be different compared to last night,
when things worked fine.

I have tried to use procmon.exe to see if I could get some information
out of there, but nothing useful jumps out.

Another odd thing:
//127.0.0.1/c$/log.txt - opens quickly
//127.0.0.1/share/log.txt - bogs down vim

Any help in locating what the problem is very welcome... !