[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UNC file names
Re: UNC file names
Fri, 10 Aug 2018 07:39:06 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
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
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.