# UNC file names

14 messages
Open this post in threaded view
|

## UNC file names

 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) _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 Knute On Tue, 24 Apr 2018 05:56:04 -0700, Knute Snortum <[hidden email]> wrote: > 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 > > > 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 >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 >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 >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 >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) _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 Hello Knute, On 24/04/18 16:50, Knute Snortum wrote: > >     > 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 > >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 > >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 > >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 > >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) > > 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/156276I 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 On 8/9/2018 10:41 AM, James Lowe wrote: > 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. -- Karlin High Missouri, USA _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 In reply to this post by James 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 In reply to this post by Karlin High Knute, On 09/08/18 18:30, Karlin High wrote: > On 8/9/2018 10:41 AM, James Lowe wrote: >> 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 In reply to this post by Aaron Hill Hello, On 09/08/18 19:02, Aaron Hill wrote: > 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. 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 Hello, On 10/08/18 07:39, James Lowe wrote: > Hello, > > > On 09/08/18 19:02, Aaron Hill wrote: >> 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. > > 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond UNC_Issue_PROCMON_logs.zip (335K) Download Attachment
Open this post in threaded view
|

## Re: UNC file names

 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. 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 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. -- Aaron Hill _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond
Open this post in threaded view
|

## Re: UNC file names

 Hello, On 10/08/18 19:03, Aaron Hill wrote: > 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. 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 _______________________________________________ bug-lilypond mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/bug-lilypond