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.
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.