On Windows: 1. Create a directory with a very long name. For instance: C:\abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqrstuvwxyz12345 The path above takes 250 characters, which is close enough to the old Windows path length limit of 260 characters. 2. In LibreOffice, create a Writer document, and use File->Save As to attempt to save to the newly created long-name directory; a file name is irrelevant, may be a simple "1.odt". This fails in 7.4 with "Error saving the document Untitled 1: Write Error. The file could not be written." This succeeded in 7.3. This is a regression from commit 92e835dbf00590c9c29509d2995cc7918a9bbb90 Author Kunal Pawar <hellokunalpawar@gmail.com> Date Fri Feb 18 19:15:04 2022 +0530 tdf#98705 Replace GetCaseCorrectPathName with GetLongPathNameW The failure happens in osl_getSystemPathFromFileURL_ called from osl_openFile called from File::open called from lcl_createName called from CreateTempName_Impl. The problem is: GetCaseCorrectPathName didn't require that the path exists; GetLongPathNameW does. So the check "if ( nDecodedLen - nSkip <= MAX_PATH - 12 )" fails, and a branch involving GetLongPathNameW (previously GetCaseCorrectPathName) triggers; it now gives an empty string as a result (because, indeed, the file doesn't yet exist there). It looks like we should re-implement the GetCaseCorrectPathName in some form, possibly using a combination of GetLongPathNameW and GetFullPathNameW, like this: first, try GetLongPathNameW; if it succeeds, return (and thus, keep the performance improvement we got in the fix for bug 98705); if it fails with "file does not exist", then use GetFullPathNameW to get the pointer to the last path segment, and repeat GetLongPathNameW with the path before the last segment, until we find a path segment that succeeds (so we get the correct case for the leading existing part, and keep the trailing non-existing part as is).
Another *possibly* related problem could be https://ask.libreoffice.org/t/file-name-changed-by-libre-office-writer-when-i-save-close-and-open-again/82076/8 - maybe when the path is not *that* long, it fails in another place.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b60dc48bb48bec63b21eb9c2ef705af64d9b9069 tdf#151117: Process non-existent long paths correctly It will be available in 7.5.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/dfdf5c310673f6c76499af7b3071879a7775ee92 tdf#151117: Process non-existent long paths correctly It will be available in 7.4.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.