Kaydet (Commit) 12e878d3 authored tarafından Mike Kaganski's avatar Mike Kaganski

tdf#98343: ensure PathRemoveFileSpec does not remove UNC's "\\"

PathRemoveFileSpec is used exclusively in GetCaseCorrectPathName(Ex).
The GetCaseCorrectPathName function is only called for absolute or
relative paths, not some arbitrary that chunks. So initial double
backslashes are only possible for UNC paths.

This change fixes handling of UNC paths by the functions. Previously,
the UNC path was recursively shortened until it only consisted of a
single "\"; then, if bCheckExistence was requested, testing this path
failed, which resulted in the whole recursion to return empty result;
else when returning from the recursion, original path components were
appended, but initial double backslashes were never restored. This led
to transformation "\\SERVER\Path\file.ext" to "\SERVER\Path\file.ext".

The GetCaseCorrectPathName itself is only used in two places:
osl_getSystemPathFromFileURL_() and osl_getFileStatus().

osl_getSystemPathFromFileURL_ only calls GetCaseCorrectPathName for
paths longer than 248 characters; bCheckExistence is false. In that
case, the resulting wrong path (missing one initial backslash) was then
processed in /* it should be an UNC path, use the according prefix */
branch, where two initial characters of it were stripped, one of which
being the first character of SERVER name. So, all the following
manipulations with resulting path were incorrect. This code path was
the reason for the bug.

osl_getFileStatus calls GetCaseCorrectPathName always; it requires
to check existence. This led to 0 returned from GetCaseCorrectPathName,
then osl_getFileStatus continued with copying the original string, thus
ignoring the error.

Change-Id: If7409afa2c0dd6dd001c79e719acbfd271a6ab72
Reviewed-on: https://gerrit.libreoffice.org/65158
Tested-by: Jenkins
Reviewed-by: 's avatarMike Kaganski <mike.kaganski@collabora.com>
üst 977a98c5
......@@ -307,11 +307,12 @@ DWORD IsValidFilePath(rtl_uString *path, DWORD dwFlags, rtl_uString **corrected)
return bValid ? dwPathType : PATHTYPE_ERROR;
}
// Expects a proper absolute or relative path
static sal_Int32 PathRemoveFileSpec(LPWSTR lpPath, LPWSTR lpFileName, sal_Int32 nFileBufLen )
{
sal_Int32 nRemoved = 0;
if ( nFileBufLen )
if (nFileBufLen && wcscmp(lpPath, L"\\\\") != 0) // tdf#98343 do not remove leading UNC backslashes!
{
lpFileName[0] = 0;
LPWSTR lpLastBkSlash = wcsrchr( lpPath, '\\' );
......@@ -361,7 +362,7 @@ static LPWSTR PathAddBackslash(LPWSTR lpPath, sal_uInt32 nBufLen)
return lpEndPath;
}
// Same as GetLongPathName but also 95/NT4
// Expects a proper absolute or relative path. NB: It is different from GetLongPathName WinAPI!
static DWORD GetCaseCorrectPathNameEx(
LPWSTR lpszPath, // path buffer to convert
sal_uInt32 cchBuffer, // size of path buffer
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment