Consider this BASIC code: Sub UseInvalidURL StarDesktop.loadComponentFromURL("file:///D:\Documents\test.odt", "_blank", 0, Array()) End Sub Given that you have such a file (D:\Documents\test.odt), this code would manage to open the file (even considering that the file URL is invalid, containing backslashes), but when opening, it will issue a warning that the lockfile couldn't be created, and offer to open it in read-only mode. A consistent behavior could be one of: * Either to disallow invalid URLs at all (so fail opening the document) - unlikely, given how widespread the use of such "URLs" is on Windows, where users simply concatenate "file:///" with the system path; * Or if they are handled, then sanitize them, so that the rest of operations would work correctly, including lockfile generation. Still, one valid outcome for this issue could be WONTFIX, based on GIGO principle. Stephan, what would you advise here - should it be fixed or not?
I repro. Stephan: please advise. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 960db01dbfe2f916b91782da03532fae1f836445 CPU threads: 2; OS: Windows 11 X86_64 (build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Mike Kaganski from comment #0) > principle. Stephan, what would you advise here - should it be fixed or not? sounds like the code that opens the file itself and the code that tries to create the associated lockfile handle the given malformed URL differently, and that it would presumably be good if they handled it in a more consistent way