UNC paths on Windows extremely slow to open

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

UNC paths on Windows extremely slow to open

Chris Edwards-2
Hi Vimmers!

I'm having problems opening files referenced by UNC ("\\server\share\file.sfx") paths from Vim.  I'm using version 6.4, "plain" GUI, on Windows XP.  Files are served by a Samba 3.0.20b server on NetBSD/amd64 2.0.2.  When opening such files, the Vim process runs, but the window does not appear for quite a few minutes, then eventually it opens.  Opening files from a share that has been mapped to a drive letter ("X:\path\file.sfx") works fine, however - Vim opens the file immediately.

Looking in the Samba logs, the path name appears to be being mangled; specifically, the last letter of the share name is disappearing.  If I try to open "\\example\etc\fstab", smbd reports the following error:

[...] smbd/service.c:make_connection(798) [...] couldn't find service et [...]

If I then create a new Samba share called "et", matching what Vim is apparently asking for, I can successfully open files under "\\example\etc\" instantly - but doing this for every share is obviously not an ideal solution! :^) I also tried adding an extra character to the share name in the original UNC path, e.g. "\\example\etcc\fstab" but this does not work - smbd again reports the service as nonexistent, referencing the entire name: "couldn't find service etcc".

Other Windows programs (e.g. Notepad) are able to open these files without any delays, so I don't believe the problem is with the Samba server.  Anyone else had similar problems or success opening UNC paths from Vim on Windows?

Thanks in advance,
--
Chris Edwards
mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: UNC paths on Windows extremely slow to open

Steve Hall-4
On Tue, 2005-11-08 at 16:06 +1300, Chris Edwards wrote:
>
> I'm having problems opening files referenced by UNC
> ("\\server\share\file.sfx") paths from Vim.  I'm using version 6.4,
> "plain" GUI, on Windows XP.  Files are served by a Samba 3.0.20b
> server on NetBSD/amd64 2.0.2.  When opening such files, the Vim
> process runs, but the window does not appear for quite a few
> minutes, then eventually it opens.  Opening files from a share that
> has been mapped to a drive letter ("X:\path\file.sfx") works fine,
> however - Vim opens the file immediately.
[snip]
> Anyone else had similar problems or success opening UNC paths from
> Vim on Windows?

UNC path mangling can sometimes happen with expansions like
fnamemodify(), expand("%", ":p"). We (Cream ) handle that with a
wrapper that identifies and corrects leading backslash pairs.

We also recently fixed a delay issue opening distant paths on Windows
traced to Vim making the remote file's path current. It was fixed
with:

  autocmd VimEnter,BufEnter * cd /tmp

or similar (where "/tmp" represents a local path).

I can forward details on either if not clear.


--
Steve Hall  [ digitect mindspring com ]


Reply | Threaded
Open this post in threaded view
|

Re: UNC paths on Windows extremely slow to open

Chris Edwards-2
----- Original Message -----
From: "Steve Hall" <[hidden email]>
To: "Chris Edwards" <[hidden email]>
Cc: <[hidden email]>
Sent: Tuesday, November 08, 2005 5:46 PM
Subject: Re: UNC paths on Windows extremely slow to open


> UNC path mangling can sometimes happen with expansions like
> fnamemodify(), expand("%", ":p"). We (Cream ) handle that with a
> wrapper that identifies and corrects leading backslash pairs.

Thanks for the quick reply, Steve.  I wondered about the backslashes possibly being interpreted strangely, but I noticed the behaviour is just the same if I use forward slashes instead.  Although now that I think about it, I guess Vim would have to translate them internally into backslashes before requesting the file, so it's probably ending up requesting the same UNC path either way.

How would I tell if Vim is using fnamemodify(), expand(), or some other expansion on the paths I'm giving it?  Or find out what final path Vim is actually using in requesting the file?  I tried applying those functions you mentioned on some UNC paths just to check, and the output looks normal - no missing final character from the share name.  Other than the smbd logs I don't have much to go on for troubleshooting.  So far I've just been testing by passing the UNC path on the command line and as an argument to :edit within Vim; both ways I get a very long wait before the file loads, accompanied by the Samba server complaining about the request for the nonexistent share.  I'm very curious as to why it's able to open the file eventually, though...

As another test, I tried opening a file from Vim from the local Windows machine via a UNC path, and it opened instantly.  This suggests that it might be a problem with the Samba server -  or specifically some interaction between smbd and Vim, since other Windows programs seem to have no trouble dealing with files on the server.


>  autocmd VimEnter,BufEnter * cd /tmp

That's a good tip about having Vim cd to a local temporary directory - it didn't resolve my problem, but definitely a good idea!
--
Chris Edwards
mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: UNC paths on Windows extremely slow to open

Steve Hall-4
On Wed, 2005-11-09 at 15:59 +1300, Chris Edwards wrote:

> From: "Steve Hall", November 08, 2005 5:46 PM
>
> > UNC path mangling can sometimes happen with expansions like
> > fnamemodify(), expand("%", ":p"). We (Cream ) handle that with a
> > wrapper that identifies and corrects leading backslash pairs.
>
> Thanks for the quick reply, Steve.  I wondered about the backslashes
> possibly being interpreted strangely, but I noticed the behaviour is
> just the same if I use forward slashes instead.  Although now that I
> think about it, I guess Vim would have to translate them internally
> into backslashes before requesting the file, so it's probably ending
> up requesting the same UNC path either way.

Vim seems to use Unix type paths natively, even on Windows. This means
path separators are slashes and spaces are escaped. If you try to use
one of these paths in a system() call, it will fail.

I often notice Vim scripts that don't realize this. We use path
processing wrappers to distinguish a valid system path vs. a valid Vim
path. Part of this is UNC recognition and restoration.

Internally, I'm not sure what Vim uses. You might put in your vimrc

  set title
  autocmd BufEnter * let &titlestring = expand("%:p")

to display it in the window title (if you're in gvim), although I
can't say if this would be the actual internal path.


--
Steve Hall  [ digitect mindspring com ]