#507 Windows: Lilypond cannot manage UNC paths

[Anonymous]

Originally created by: gpermus@gmail.com

I am trying to double-click a .ly file that is in a network share. When I
do so, the following log file is created:

------------
# -*-compilation-*-
warning: can't find file:
`\\server\fgasper\my_docs\Scores\editions\conditor3-alt_lyrics.ly'
error: failed files:
"\\\\server\\fgasper\\my_docs\\Scores\\editions\\conditor3-alt_lyrics.ly"
------------

If I copy the file to my Windows desktop and double-click on it there,
everything works as normal.

Also see: https://sourceforge.net/p/testlilyissues/issues/1002/

[Google Importer]

Originally posted by: jermi...@gmail.com

I can confirm that this bug exists in 2.12.3.1 modified 12/15/2009 2:57 PM on Windows
7.

This is especially a problem if your user folders (desktop, documents, etc) are using
folder redirection via GPO and are not stored locally. Same log file contents with path
to redirected network UNC location.

error: failed files: "\\\\Domain_Name\\dfs\\Profiles\\User_Name\\Desktop\\test.ly"

[Google Importer]

Originally posted by: pnorcks@gmail.com

Hmm, not sure how to fix this one (yet) ...

Owner: ---

[Anonymous]

My tests on Windows 10 indicate that lilypond.exe can't handle UNC
notation. This is true even of a local file.

First I "type" the file and it works fine with UNC. Then I try to launch
LilyPond with the same file name and it can't find the file.

Bug or future feature?

C:\Users\Knute\Desktop
> type \\KNUTE-HP\Users\Knute\Desktop\test.ly
\version "2.19.81"

{ c'4 d' e' f' }
C:\Users\Knute\Desktop
> lilypond \\KNUTE-HP\Users\Knute\Desktop\test.ly
GNU LilyPond 2.19.81
warning: cannot find file: `\\KNUTE-HP\Users\Knute\Desktop\test.ly'
fatal error: failed files: "\\\\KNUTE-HP\\Users\\Knute\\Desktop\\test.ly"

---

Knute Snortum
(via Gmail)

[Anonymous]

On 2018-08-09 08:41, James Lowe wrote:

Sorry this took so long for me to get back to you.

More research tells me that it is not lilypond that is at fault here
but Windows.

Windows cmd does not support UNC paths.

That should not be relevant, though. That at most limits the ability for the current working directory to be a UNC path, without first mapping it to a drive letter. But it really should not affect the ability to invoke LilyPond and pass in a UNC path for the input file. As an aside, PowerShell does not have the same working directory limitation, and you can cd to a UNC path as you wish.

But back to the issue, if LilyPond is ultimately calling CreateFile passing in the file path as specified in the command-line arguments, it should be able to open a UNC-based path providing there are no permissions issues. What I would suspect is some quirkiness with MinGW/MSYS and Posix paths such that LilyPond is not generating the correct API call.

As such, what would be interesting is to get a Process Monitor capture of the failing case. That way, we can see which specific file I/O calls failed and with which errors. Unfortunately, I no longer use the Windows version of LilyPond, so I cannot immediately test this on my setup without having to set up a VM first. If it is possible to run LilyPond in a portable mode without installation, then that would save significant time getting a test environment.

-- Aaron Hill

[Anonymous]

Here are some procmon csv logs

Three of them (zipped)

1. Where I ran it from a local dir - success
2. Where I ran it on a UNC share - fail
3. Where I pushd the UNC share (mounts on W:) and then run - success

Hope this is useful.

James

[Anonymous]

Hi James,

Thanks for taking the time to capture this data! This confirms LilyPond is not passing the expected path to CreateFile. Why it is not, I will do more research and see if I can track down the underlying cause.

For the time-being, though, we should just recommend folks manually map network paths to drive letters, since that seems to work fine.

-- Aaron Hill

[Anonymous]

flower/file-name.cc:57
  replace_all (&file_name, string ("//"), "/");

There's the likely culprit there. The slashify function first forces backslashes to forward slashes. While Windows does permit some use of forward slashes where backslashes are the standard, there is most definitely a difference between \\ and \, when it is at the beginning of a file path. And the problem is that slashify collapses double slashes to single ones, thereby changing the intention of the input path.

lilypond \\server\folder\file results in a file path of /server/folder/file, which then results in looking at C:\server\folder\file (if the current working directory is the C: drive). If the original path were preserved as \\server\folder\file (or possibly even mildly mutilated as //server/folder/file), then CreateFile should see the path as absolute, not relative, and attempt to read the from the specific network path.

So the logic for detecting an absolute path needs some updating for Windows. An explicit drive letter is one option but a leading \\ (or \\?\) should be recognized and preserved.

-- Aaron Hill

[Masamichi Hosoda]

Why do we replace // to /?
If it is not absolutely necessary, removing the following line might solve the issue.

replace_all (&file_name, string ("//"), "/");