https://bugs.documentfoundation.org/show_bug.cgi?id=151117
Bug ID: 151117
Summary: Saving to a directory with very long name fails
Product: LibreOffice
Version: 7.4.0.3 release
Hardware: All
OS: Windows (All)
Status: UNCONFIRMED
Keywords: bibisected, bisected, regression
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
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 <[email protected]>
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).
--
You are receiving this mail because:
You are the assignee for the bug.
