GetShortPathName unpredictable results

Question

GetShortPathName () does not work as I expect on XP SP3

http://msdn.microsoft.com/en-us/library/aa364989(VS.85).aspx

Returns an input string for paths such as:

C:\Test\LongFolderNameToTestWith\BinarySearch.ini 

exactly how is it sent?

Nonetheless:

 C:\Documents and Settings\LocalService\NTUSER.DAT 

Makes short names for the path, so I know that I am calling the API correctly.

But:

 C:\Documents and Settings\LocalService\BinarySearch.ini 

Does not output the short name from the file name, but does short names for the path !?

Can someone help me understand this behavior and maybe suggest a workaround.

Added:

I need 8.3 Path / filename to go to deprecated application

How can I do that?

Added: SOLUTION

After reading / experimenting repeatedly, it seems that the only reliable way to do this is to use automation:

 ' ------------------------------------------------------------ ' Library Name: Microsoft Scripting Runtime 1.0 ' Library File: C:\WINDOWS\system32\scrrun.dll ' ------------------------------------------------------------ ' Version Info: ' ------------- ' Company Name: Microsoft Corporation ' File Description: Microsoft (R) Script Runtime ' File Version: 5.7.0.16599 ' Internal Name: scrrun.dll ' Legal Copyright: Copyright (C) Microsoft Corp. 1996-2006, All Rights Reserved ' Original Filename: scrrun.dll ' Product Name: Microsoft (R) Script Runtime ' Product Version: 5.7.0.16599 ' ------------------------------------------------------------ ' ProgID: Scripting.FileSystemObject ' Interface Name: ScriptingFileSystemObject ' ' Interface Prefix: Scripting 

It works.

Simple implementation in BASIC:

 $PROGID_ScriptingFileSystemObject = "Scripting.FileSystemObject" Interface Dispatch ScriptingFileSystemObject Member CALL GetFile <&H0000271C>(IN FilePath AS STRING<&H00000000>) AS ScriptingIFile Member CALL GetFolder<&H0000271D>(IN FolderPath AS STRING<&H00000000>) AS ScriptingIFolder END Interface Interface Dispatch ScriptingFile Member GET ShortPath<&H000003EA>() AS STRING Member GET ShortName<&H000003E9>() AS STRING END Interface Interface Dispatch ScriptingFolder Member GET ShortPath<&H000003EA>() AS STRING Member GET ShortName<&H000003E9>() AS STRING END Interface '----------------------------------------------------------------------------- FUNCTION FileShortPath( BYVAL sPathnFile AS STRING, sShort AS STRING ) AS LONG LOCAL vResult, vFilePath AS Variant LOCAL fso AS ScriptingFileSystemObject LOCAL oFile AS ScriptingFile IF LEN(sPathnFile) = 0 THEN EXIT FUNCTION ' Nothing sent SET fso = NEW ScriptingFileSystemObject IN $PROGID_ScriptingFileSystemObject IF IsNothing(fso) THEN FUNCTION = -1 : EXIT FUNCTION SET oFile = NEW ScriptingFile IN $PROGID_ScriptingFileSystemObject IF IsNothing(oFile) THEN FUNCTION = -2 : EXIT FUNCTION vFilePath = sPathnFile vResult = Empty OBJECT CALL fso.GetFile(vFilePath) TO vResult SET oFile = vResult IF IsNothing(oFile) THEN FUNCTION = -3 : EXIT FUNCTION vResult = Empty Object GET oFile.ShortName TO vResult sShort = VARIANT$(vResult) vResult = Empty Object GET oFile.ShortPath TO vResult sShort = VARIANT$(vResult) IF LEN(sShort) THEN FUNCTION = 1 ' Success END FUNCTION 

Thank you all for your suggestions.

---

I'm still trying to find a way to reliably make 8.3 Path / filename.

Is there a way to do this separately from using GETSHORTPATHNAME?

solved. See above

It seems that MS continues to support this only for COM extensions ... why it is now unreliable in the C API remains a mystery.

Answer 1

This is because the file name does not have a short name, and XP SP3 does not automatically create a short name for the file.

You can check this registry entry (if one exists) to see what it is installed on.

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ FileSystem \ NtfsDisable8dot3NameCreation

When NtfsDisable8dot3NameCreation is set to 1, you will get the following behavior:

If the folder / file already has a short name, for example, "Program Files", then it will return the short name for this folder / file. But if the short name does not exist, instead you will get a long name for the file, since it is the only name that exists for this object. If short names are disabled, the short name will not be received.

Answer 2

According to the earlier documentation, short names will only be generated if NtfsDisable8dot3NameCreation is 0. If the value has been changed, you may have some files / directories with long names. This explains why your GetShortPathName call may contain short names for the directory and long names for the file.

I could not confirm this, but I suspect that there may be a special logic in Windows that always creates short names for critical directories, such as Documents and Settings, because some ancient programs may break if this was not done.

Answer 3

Have you tried SetFileShortName ?