UNC file names

[Knute Snortum]

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?

*** Start command line
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"
*** End command line

---
Knute Snortum
(via Gmail)

[James Lowe]

Knute

Post by Knute Snortum
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?

We had a few Windows-related issue - I think they are still needing some documentation in the 'running' doc - where some commands needed double quotes around the 'path to file name' and some single quotes.

Could you try that and see if that helps?

James

[Knute Snortum]

Post by James Lowe

Post by Knute Snortum
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?

We had a few Windows-related issue - I think they are still needing some
documentation in the 'running' doc - where some commands needed double
quotes around the 'path to file name' and some single quotes.
Could you try that and see if that helps?

No combination of slash or quote types worked for me.

C:\Users\Knute\Desktop

Post by James Lowe
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"

C:\Users\Knute\Desktop

Post by James Lowe
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'"

C:\Users\Knute\Desktop

Post by James Lowe
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'"

C:\Users\Knute\Desktop

Post by James Lowe
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)

[James Lowe]

Hello Knute,

Post by Knute Snortum

Post by Knute Snortum
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

Post by Knute Snortum
LilyPond with the same file name and it can't find the file.
Bug or future feature?

We had a few Windows-related issue - I think they are still
needing some documentation in the 'running' doc - where some
commands needed double quotes around the 'path to file name' and
some single quotes.
Could you try that and see if that helps?
No combination of slash or quote types worked for me.
C:\Users\Knute\Desktop

Post by Knute Snortum
lilypond "//KNUTE-HP/Users/Knute/Desktop/test.ly <http://test.ly>"

GNU LilyPond 2.19.81
warning: cannot find file: `//KNUTE-HP/Users/Knute/Desktop/test.ly
<http://test.ly>'
fatal error: failed files: "//KNUTE-HP/Users/Knute/Desktop/test.ly
<http://test.ly>"
C:\Users\Knute\Desktop

Post by Knute Snortum
lilypond '//KNUTE-HP/Users/Knute/Desktop/test.ly <http://test.ly>'

GNU LilyPond 2.19.81
warning: cannot find file: `'//KNUTE-HP/Users/Knute/Desktop/test.ly
<http://test.ly>''
fatal error: failed files: "'//KNUTE-HP/Users/Knute/Desktop/test.ly
<http://test.ly>'"
C:\Users\Knute\Desktop

Post by Knute Snortum
lilypond '\\KNUTE-HP\Users\Knute\Desktop\test.ly <http://test.ly>'

GNU LilyPond 2.19.81
warning: cannot find file: `'\\KNUTE-HP\Users\Knute\Desktop\test.ly
<http://test.ly>''
"'\\\\KNUTE-HP\\Users\\Knute\\Desktop\\test.ly <http://test.ly>'"
C:\Users\Knute\Desktop

Post by Knute Snortum
lilypond "\\KNUTE-HP\Users\Knute\Desktop\test.ly <http://test.ly>"

GNU LilyPond 2.19.81
warning: cannot find file: `\\KNUTE-HP\Users\Knute\Desktop\test.ly
<http://test.ly>'
"\\\\KNUTE-HP\\Users\\Knute\\Desktop\\test.ly <http://test.ly>"
---
Knute Snortum
(via Gmail)

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.

Also see:

https://web.archive.org/web/20150312195558/https://support.microsoft.com/en-us/kb/156276

I tried the registry edit mentioned here too but on my 8.1 OS it didn't
seem to change anything.

You can use the pushd/popd commands - example:

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Users\jlowe>lilypond x:\test.ly
GNU LilyPond 2.19.82
warning: cannot find file: `x:\test.ly'
fatal error: failed files: "x:\\test.ly"

C:\Users\jlowe>pushd x:\

x:\>lilypond test.ly
GNU LilyPond 2.19.82
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `./tmp-lilypond-sOMY4M'...
Converting to `test.pdf'...
Deleting `./tmp-lilypond-sOMY4M'...
Success: compilation successfully completed

x:\>popd

C:\Users\jlowe>

I hope this helps.

James

[Karlin High]

Post by James Lowe
Windows cmd does not support UNC paths.

Does it work if the UNC path gets mapped as a network drive? That could
even be automated on the command line with the NET USE command.

[James Lowe]

Knute,

Post by Karlin High

Post by James Lowe
Windows cmd does not support UNC paths.

Does it work if the UNC path gets mapped as a network drive? That
could even be automated on the command line with the NET USE command.

That is effectively, as far as I can tell, what the pushd and popd
commands do.

James

[Aaron Hill]

Post by James Lowe
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

[James Lowe]

Hello,

Post by James Lowe
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.

Possibly but I would guess that would only matter if you were running
the command in cmd rather than a ps environment.

As an aside, PowerShell does not have the same working directory
limitation, and you can `cd` to a UNC path as you wish.

Yes this is true and also of note I could not get LP to use UNC paths
even when run from Powershell, so perhaps your previous paragraph is
making this point?

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.

Yes, although that is well beyond my ken.

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.

I can do that perhaps - although I haven't used proc mon for a while.

James

[James Lowe]

Hello,

Post by James Lowe
Hello,

Post by James Lowe
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.

Possibly but I would guess that would only matter if you were running
the command in cmd rather than a ps environment.

As an aside, PowerShell does not have the same working directory
limitation, and you can `cd` to a UNC path as you wish.

Yes this is true and also of note I could not get LP to use UNC paths
even when run from Powershell, so perhaps your previous paragraph is
making this point?

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.

Yes, although that is well beyond my ken.

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.

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

[Aaron Hill]

Post by James Lowe
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.

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

[Aaron Hill]

Post by Aaron Hill

Post by James Lowe
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.


-- Aaron Hill

[James Lowe]

Hello,

Post by Aaron Hill

Post by Aaron Hill

Post by James Lowe
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
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.

I went digging through the tracker and came up with an old issue that we
could tack this thread onto

https://sourceforge.net/p/testlilyissues/issues/507/

I'll update that and change the title of the issue.

There is another related tracker (I think) that is also still open

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

James

[maanshic]

AOL is the best independent organization that provides AOL Customer Service
for any glitches. In case user faces issues with the account can connect
with Delete AOL Account
<https://www.aoltechsupportnumber.com/blog/how-to-close-a-free-aol-account/>
. Our qualified technicians who are experienced and provides with best of
support services. Our expert technical support providers are here to provide
all the necessary technical solutions that will resolve the issues in no
time.




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html

[maanshic]

AOL is the best independent organization that provides AOL Customer Service
for any glitches. In case user faces issues with the account can connect
with Delete AOL Account
<https://www.aoltechsupportnumber.com/blog/how-to-close-a-free-aol-account/>
. Our qualified technicians who are experienced and provides with best of
support services. Our expert technical support providers are here to provide
all the necessary technical solutions that will resolve the issues in no
time.




--
Sent from: http://lilypond.1069038.n5.nabble.com/Bugs-f58488.html