[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UNC file names

From: Aaron Hill
Subject: Re: UNC file names
Date: Fri, 10 Aug 2018 11:03:51 -0700
User-agent: Roundcube Webmail/1.3.6

On 2018-08-10 10:29, Aaron Hill wrote:
On 2018-08-10 08:52, James Lowe wrote:
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.

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.

  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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]