BUG: GetShortPathName May Fail When Passed a Remote Long File Name
ID: Q238817
|
This article discusses a Beta release of a Microsoft product. The
information in this article is provided as-is and is subject to change
without notice.
No formal product support is available from Microsoft for this Beta
product. For information about obtaining support for a Beta release,
please see the documentation included with the Beta product files, or
check the Web location from which you downloaded the release.
The information in this article applies to:
-
Microsoft Win32 Application Programming Interface (API), on platform(s):
-
Microsoft Windows NT versions 3.51, 4.0
SYMPTOMS
On Windows NT versions 4.0 and earlier, the GetShortPathName function works correctly for remote files with long file names only when those files reside on another Windows NT or Windows 2000 computer. If the other computer is not Windows NT or Windows 2000, GetShortPathName returns ERROR_NOT_SUPPORTED(50).
STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed
at the beginning of this article.
MORE INFORMATION
On Windows platforms, file I/O functions between two computers are carried out by the two computers' network redirectors via the Server Message Block (SMB) protocol. Every file I/O function that targets another computer causes the client computer's redirector to generate an SMB and send it to the server. After the server carries out the SMB, its redirector sends back an SMB with the results--a file handle in the case of CreateFile, a file name in the case of GetShortPathName, and so on.
The problem with GetShortPathName occurs because the client-side redirector for Windows NT 4.0 only sends the SMB for GetShortPathName to Windows NT SMB servers; it does not send the SMB for GetShortPathName to Windows 95 or other SMB servers (Windows For Workgroups, and so on).
RESOLUTION
To work around this problem, use the FindFirstFile function. The returned WIN32_FIND_DATA structure contains a cAlternateFileName member that is filled out with the short file name but not the full path. The following code example shows how to use this workaround:
/*-----------------------------------------------------------------------
getshort.c
This program retrieves the short file name from a long file name. It
demonstrates how to use FindFirstFile() to work around the case where
GetShortPathName returns ERROR_NOT_SUPPORTED when called on a Windows NT
4.0 system to retrieve the short path of a remote file residing on a
non-Windows NT computer.
Use:
getshort <filename>
-----------------------------------------------------------------------*/
#include <windows.h>
#include <stdio.h>
void main (int argc, char *argv[])
{
char *pszFileName;
char szShortFileName[MAX_PATH];
DWORD cchShortNameLength;
BOOL fResult;
if (argc != 2)
{
printf("usage: %s <filename>\n", argv[0]);
return;
}
pszFileName = argv[1];
cchShortNameLength = GetShortPathName (pszFileName,
szShortFileName,
sizeof(szShortFileName));
fResult = ((0 != cchShortNameLength) &&
(cchShortNameLength <= sizeof(szShortFileName)));
/*
If GetShortPathName fails with ERROR_NOT_SUPPORTED, use
FindFirstFile workaround to get short file name. Note that the <BR/>
workaround retrieves just the short file name; it does not retrieve
the entire path in short format.
*/
if (!fResult && (GetLastError() == ERROR_NOT_SUPPORTED))
{
HANDLE hFind;
WIN32_FIND_DATA fd;
hFind = FindFirstFile (pszFileName, &fd);
if (INVALID_HANDLE_VALUE != hFind)
{
lstrcpy (szShortFileName, fd.cAlternateFileName);
FindClose (hFind);
fResult = TRUE;
}
}
if (fResult)
printf("the short name of %s is %s\n", pszFileName, szShortFileName);
else
printf("couldn't retrieve short name for %s\n", pszFileName);
}
Additional query words:
Keywords : kbAPI kbFileIO kbKernBase kbNTOS400 kbWinOS2000fix kbSDKWin32 kbDSupport kbGrpKernBase
Version : winnt:3.51,4.0
Platform : winnt
Issue type : kbbug