Description: I have used Libre Calc on Windows 11 as the default app for opening .csv files for some while. Out of the blue, it stopped working. I looked the command up in the Windows registry and tried to duplicate it in a PowerShell using the path that a right-click>Copy as path gets me from the Windows explorer. Turns out, the file path was prepended with \\?\. Running Calc with that as an argument sees Calc end silently and do nothing. If I remove this prefix, Calc opens the CSV file and all is good. Turns out this prefix is used (as is \\?\UNC\) by the Windows API when paths are longer than some erstwhile path length limit to flag to users that it's a long one. Alas, LibreOffice is unaware of the convention. No surprise there. But given any cross-platform app has to accommodate filesystem idiosyncrasies across those systems. And it seems this is any easy thing to accommodate and arguably should for smooth cross-platform functioning (i.e helping me overcome internal resistance to using LibreOffice here - but alas it is simply way better than excel in so many subtle ways I am always drawn to it). Steps to Reproduce: 1. Try top open a file in LibreOffice from the command line by using a long path that Windows Copy as path provides with a \\?\ prefix. 2. Try again, removing that prefix. Actual Results: The file is not opened. Expected Results: The file opens. Reproducible: Always User Profile Reset: No Additional Info: I clearly don't have the latest version, but am constrained to use portable versions (thanks to PortableApps). I will see if they have a later one and be back and close this if it happens to be fixed of course. Opted for file first as I searched Bugzilla for "\\?\" and found nothing so I doubt this has ever been spotted to be honest. It arises only with very long paths. I don't know the exact length, but the one I'm using has 278 chars so I imagine this prefix kicks in at 256 and longer.
Confirmed the bug exists in 7.6.2.1 as well. No surprise. It reports as: LibreOffice 7.6.2.1 56f7684011345957bbf33a7ee678afaf4d2ba333
I should add this prefix and its meaning is discussed here, with references to MS source docs: https://stackoverflow.com/questions/21194530/what-does-mean-when-prepended-to-a-file-path
If this issue cannot be replicated, I would suggest to highlight it's not a standard installation. Just a suggestion
But it can be replicated. Create a path longer than 256 chars, drop a CSV file there. Right-click in Windows explorer and click Open With and from there click wherever you need to, to browse for an exe, and find LibreOfficeCalc.exe, select that. You will find on Windows 11 (and probably older versions too) LibreOffice Calc will not open the CSV. Move the CSV file to a path less than 255 chars long, and repeat. You will find it does open CSV.
I see. But again it was just a suggestion. That's all (I might be wrong). Can you reproduce this also using the Open File dialog provided by Libreoffice?
I actually don't know if Libreoffice provide the dialog or just call the file explorer (that seems to be the right thing to do nowadays at least on linux). I'm not even using Windows. You don't have to provide that information if you don't want to, I'm not the person that will work on this
The fix is simple. If on an MS-Windows system then: 1) Remove any prefix from a file path that is "\\?\UNC\" 2) Remove any prefix from a file path that is "\\?\" In that order. That's what I do as a work around by opening it with this Powershell script rather than with LibreOffice directly Calc.ps1: param( [Parameter(Mandatory=$true)] [string]$Path ) [regex]$pattern1 = [regex]::Escape("\\?\UNC\") $Path = $pattern1.replace($Path, "\\", 1) [regex]$pattern2 = [regex]::Escape("\\?\") $Path = $pattern2.replace($Path, "", 1) & E:\Util\LibreOffice\LibreOfficeCalcPortable.exe "$Path" (Note I keep a binary for Calc at E:\Util\LibreOffice\LibreOfficeCalcPortable.exe) And then I can associate that by using this registration file patch: Calc.reg: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\SystemFileAssociations\.csv\shell\OpenCSVwithCalc] @="Open with Calc" [HKEY_CLASSES_ROOT\SystemFileAssociations\.csv\shell\OpenCSVwithCalc\command] @="powershell.exe -NonInteractive -WindowStyle Hidden -File \"E:\\Util\\LibreOffice\\Calc.ps1\" \"%1\"" And no all is good for me, and my shortcut menu. But the bug remains. To be reliably cross-platform all LibreOffice needs to do is update its Windows file path handler (I presume it already handles Windows and *nix paths differently if only because of the \ vs / difference, and the reality of drive letters. Wherever Windows paths are handled, these prefixes simply need to be stripped from the path before continuing (they are Windows way of telling a client the path is long, but not valid parts of a path, and one might rightly argue that is one silly way to communicate this).
(In reply to Federico Gallo from comment #6) > I actually don't know if Libreoffice provide the dialog or just call the > file explorer (that seems to be the right thing to do nowadays at least on > linux). I'm not even using Windows. > You don't have to provide that information if you don't want to, I'm not the > person that will work on this I think you misunderstand the bug. I am using LibreOffice on the command line. I am not using the File Open dialog. I did a quick test and long paths (over 256 chars) open fine with Open File dialog box. Not a problem. But when you try and open one on the command line as follows say: CD MyVeryDeepLongDIr "E:\Util\LibreOffice\LibreOfficeCalcPortable.exe" MyFIle then LibreOffice pops up: E:\Util\LibreOffice\Wideband freq response - ByRegionsAll - Sv nonAvg - upward-facing transducer_transposed.CSV does not exist. A totally bizarre thing to report. And if I try it with the full path as delivered by the Explorer when I right-click and rhen click Copy as path, then LibreOffice does nothing at all. The copied path (and so the one that Open With is passed also by the explorer is prepended with "\\?\". If I remove that, and try again, LibreOffice starts and loads the file. Summary: File Open dialog box is all good Receiving paths from the command line is broken for long paths (>256 chars) because of a prefix Windows provides to the path to indicate it is long, but which is not understood by whatever method LibreOffice subsequently tries to open same file.
Bug 157254 should have solved the problem with long paths and the portable version. I tested with 7.6.2 portable and this path Z:\0000.Bible.PCEtw6b3 italic paragraphOnly2Cols LibreOffice.Reset_pretty\Configurations2\accelerator\fdgdfgfdgdfgfdgdfgdfgdfgdfgfdgfdgdfgfdgdfgdfgdfgfdgfdgdfgfdgfdg\fgkjdfgkjfdglkjfdglkjdfgkljfdgkljdfgkljfdgkljfdgkljdfgkljdfgkljdfgkljdfgkjldfg\14fgfdgdfg.odp and it opened fine. It has 259 characters (or are the slashes not counted?) I don't see any \\?\ prefix when copying. But Windows also does not allow me to create paths that are too long, so how should we test this?! Adding Mike to Cc.
Indeed, LibreOffice knows the \\?\ prefix (and its UNC variant). See e.g. https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file_url.cxx?r=d7910847#48 The problem is, that we somehow do not handle it in the command line parameters. The reproduction is simple. Try to run on Windows: > path\to\soffice \\?\C:\Path\to\file.txt See that it fails (LibreOffice starts and silently exits - our usual behavior, when file is not found). Then run this: > notepad \\?\C:\Path\to\file.txt and see that it opens OK. Check also: > path\to\soffice C:\Path\to\file.txt to see that the file could be opened in LO.
https://gerrit.libreoffice.org/c/core/+/158741
(In reply to Buovjaga from comment #9) > Bug 157254 should have solved the problem with long paths and the portable > version. > > I tested with 7.6.2 portable and this path > > Z:\0000.Bible.PCEtw6b3 italic paragraphOnly2Cols > LibreOffice. > Reset_pretty\Configurations2\accelerator\fdgdfgfdgdfgfdgdfgdfgdfgdfgfdgfdgdfg > fdgdfgdfgdfgfdgfdgdfgfdgfdg\fgkjdfgkjfdglkjfdglkjdfgkljfdgkljdfgkljfdgkljfdgk > ljdfgkljdfgkljdfgkljdfgkjldfg\14fgfdgdfg.odp > > and it opened fine. It has 259 characters (or are the slashes not counted?) > > I don't see any \\?\ prefix when copying. > > But Windows also does not allow me to create paths that are too long, so how > should we test this?! > > Adding Mike to Cc. Good questions! So I tried to reproduce your scenario. And got your result. That is, if I make that path then I used Explorer's right-click and copy as path, it presents: "E:\0000.Bible.PCEtw6b3 italic paragraphOnly2Cols LibreOffice.Reset_pretty\Configurations2\accelerator\fdgdfgfdgdfgfdgdfgdfgdfgdfgfdgfdgdfgfdgdfgdfgdfgfdgfdgdfgfdgfdg\fgkjdfgkjfdglkjfdglkjdfgkljfdgkljdfgkljfdgkljfdgkljdfgkljdfgkljdfgkljdfgkjldfg\14fgfdgdfg.odp" So I tried it in my earlier context on a network share. And I found that I had to make the path longer (as it's a share and I only want to write into a quiet personal area on it). This did replicate my experience. So I reproduced that exact path again on my local drive and it still reprodcued. I copy these two paths (S: being a network drive and E: a local drive): "\\?\S:\! QA\Testing Files\Users\Bernd\0000.Bible.PCEtw6b3 italic paragraphOnly2Cols LibreOffice.Reset_pretty\Configurations2\accelerator\fdgdfgfdgdfgfdgdfgdfgdfgdfgfdgfdgdfgfdgdfgdfgdfgfdgfdgdfgfdgfdg\fgkjdfgkjfdglkjfdglkjdfgkljfdgkljdfgkljfdgkljfdgkl\14fgfdgdfg.odp" "\\?\E:\! QA\Testing Files\Users\Bernd\0000.Bible.PCEtw6b3 italic paragraphOnly2Cols LibreOffice.Reset_pretty\Configurations2\accelerator\fdgdfgfdgdfgfdgdfgdfgdfgdfgfdgfdgdfgfdgdfgdfgdfgfdgfdgdfgfdgfdg\fgkjdfgkjfdglkjfdglkjdfgkljfdgkljdfgkljfdgkljfdgkl\14fgfdgdfg.odp" Conclusion: The path has to be just a bit longer it seems. Observations along the way: 1. Yes, when I tried and copy the folder "0000.Bible.PCEtw6b3 italic" to the network drive, Windows refused, and created only some of the tree, up to a point, with a pop up dialog that says the path is too long. 2. Given I have paths that are too long and that there's a convention for representing them. it must be possible so I tried by making each subdir one after the other by hand, and then I copied the .odp file into the bottom folder. Explorer permitted that. So Explorer is not much of a gatekeeper in that regard, just a bother. The original use case I reported involved my creating files programmatically (in a Python script) and they are placed in subfolders by that script and these run on a network drive in project based folder etc, and so in that case it seems, I did get over that limit. 3. The limit is not clear. Your path was 259 chard long and didn't see Copy as path adding the long file path prefix. When I put it in a user based subfolder it grew to 262 chars and did reproduce the problem. Seems my inference of a limit at 256 was wrong, though only the Gods (and a few MS engineers maybe) might know why there's a limit between 259 and 292 (oh and when I reproduced your path on the network drive by hand, clearly I missedd a level ;-). But I still went over the limit it seems. So to reproduce it I'd use a programmatic approach. In Python it's as simple as: path=r"E:\! QA\Testing Files\Users\Bernd\0000.Bible.PCEtw6b3 italic paragraphOnly2Cols LibreOffice.Reset_pretty\Configurations2\accelerator\fdgdfgfdgdfgfdgdfgdfgdfgdfgfdgfdgdfgfdgdfgdfgdfgfdgfdgdfgfdgfdg\fgkjdfgkjfdglkjfdglkjdfgkljfdgkljdfgkljfdgkljfdgkl2" os.makedirs(path, exist_ok=True) I just tried that and checked and it works fine: Python 3.11.0 (main, Oct 24 2022, 18:26:48) [MSC v.1933 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> path=r"E:\! QA\Testing Files\Users\Bernd\0000.Bible.PCEtw6b3 italic paragraphOnly2Cols LibreOffice.Reset_pretty\Configurations2\accelerator\fdgdfgfdgdfgfdgdfgdfgdfgdfgfdgfdgdfgfdgdfgdfgdfgfdgfdgdfgfdgfdg\fgkjdfgkjfdglkjfdglkjdfgkljfdgkljdfgkljfdgkljfdgkl2" >>> os.makedirs(path, exist_ok=True) >>> Hope that helps.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9f1289f1e3c9b4a5f2be7a7187877db6b5015973 tdf#157820: handle \\?\ prefixes in INetURLObject It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Bernd Wechner from comment #12) > 3. The limit is not clear. Your path was 259 chard long and didn't see Copy > as path adding the long file path prefix. When I put it in a user based > subfolder it grew to 262 chars and did reproduce the problem. Seems my > inference of a limit at 256 was wrong, though only the Gods (and a few MS > engineers maybe) might know why there's a limit between 259 and 292 The limit is documented to be 260 (including terminating null) - see [1]. This number is also explained there: it results from "D:\some 256-character path string<NUL>". [1] https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
> The limit is documented to be 260 (including terminating null) - see [1]. This > number is also explained there: it results from "D:\some 256-character path > string<NUL>". Why thank you for that link and clarification. So it is in fact 256 chars plus one for a drive letter, one for a colon, one for a backslash and one for a terminating null, to bring us to 260 ;-). Intriguing. Suggests that some time in past just the path (without the drive letter, colon, backslash or terminating null were stored in a 256 byte field somewhere (but that is mere historic speculation).
Yes, it originated from FAT32 limitation (and indeed, the drive letter itself wasn't a part of what was stored in the FAT).
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/83aa3504e7690f096e840c74ca4c09035e343f09 tdf#157820: handle \\?\ prefixes in INetURLObject It will be available in 7.6.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.