FileGetLongName and the Loss of an Undocumented Feature...

[Kilmatead]

Yes, I know, one can hardly complain when an undocumented feature is "removed" from a function, but just out of my own curiosity (as it's script-changing), I'm wondering if it was intentional or just a random side-effect.

Essentially (in pre-3.3.12.0) FileGetLongName was a convenient means of regularising the "case" of a given qualified path:

FileGetLongName("c:program files") would return "C:Program Files", etc.

Since NTFS is case-agnostic this had no impact on actual usage, but it was infinitely useful when users would type in a location, and you could clean up the (verified) text before displaying the path, especially when it came to relative-path transformations.  Since 3.3.12.0. however, it does no case-correction at all, and seems to behave exactly the same as _WinAPI_GetFullPathName.

Now, obviously this isn't the end of the world - a raggety-line of 5 nested functions can accomplish the behaviour I expect:

FileGetLongName(FileGetShortName(StringUpper(StringLeft($sFile, 1)) & StringMid($sFile, 2)))

 

...but hey, 5:1 isn't really a bad ratio. (Yes, the extra string functions are needed as the drive letter itself remains lower-case, while the rest is auto-corrected - all in all it's still easier than dancing along the components rebuilding the path manually by reading each from the drive.)

Anyway, is there now any benefit to using the inbuilt function over the API call, or is this just a quirk effecting only me?

[BrewManNH]

You could use _StringTitleCase to clean up the text if you wanted to use a single function.

[Kilmatead]

_StringTitleCase doesn't have any relation to the actual pathname on the disc itself - it's just a blind-formatter.  I'm talking about retrieving the actual case contained within the filenames themselves.  True, as I said above, it's a purely aesthetic thing (unless you play with FILE_FLAG_POSIX_SEMANTICS cross-platform nomenclature), but there's no end of workaround threads on stackoverflow related to it - so somebody besides me must pay attention to these things.  I just always found it convenient that it was built-in to the native FGLN function - and now it's not.

Edited June 2, 2014 by Kilmatead

[BrewManNH]

_StringTitleCase doesn't have any relation to the actual pathname on the disc itself - it's just a blind-formatter.

Neither does this have any relation to the path name returned, I was merely making a counter suggestion to your 5 functions and just using one.

 

FileGetLongName(FileGetShortName(StringUpper(StringLeft($sFile, 1)) & StringMid($sFile, 2)))

[Kilmatead]

...except in this case that "one" function doesn't actually do anything useful (it only capitalises an arbitrary string) - the 5-function example returns the existing case of whatever filesystem object you point it at, that's what I'm referring to.  I could use _WinAPI_GetFinalPathNameByHandle, except that doesn't exist in XP and it also doesn't always return the given path (in the case of links).

Like I said, the workaround isn't important (as long as it works), I'm just curious about the change in the original function - since it doesn't seem to be much different, otherwise.

[BrewManNH]

Here's a quick proof of concept script I threw together that will allow you to fix the issue until something official comes along. One function call, and no UDFs needed.

$sFile = "c:\progra~1\"
$sFile1 = "c:\pRoGraM fiLes"
ConsoleWrite(FileGetLongName(FileGetShortName(StringUpper(StringLeft($sFile, 1)) & StringMid($sFile, 2))) & @CRLF)
ConsoleWrite(FileGetLongName(FileGetShortName(StringUpper(StringLeft($sFile1, 1)) & StringMid($sFile1, 2))) & @CRLF)
ConsoleWrite(FileGetLongName($sFile) & @CRLF) ; correct case returned
ConsoleWrite(FileGetLongName($sFile1) & @CRLF) ; <<<<<<<<<< wrong case returned
ConsoleWrite($sFile & ' => ' & _WinAPI_GetCaseCorrectLongFileName($sFile) & @CRLF) ; works with short path/file names
ConsoleWrite($sFile1 & ' => ' & _WinAPI_GetCaseCorrectLongFileName($sFile1) & @CRLF) ; and long path/file names, even with the case wrong
Func _WinAPI_GetCaseCorrectLongFileName($sFile)
    Local $Ret = DllCall('kernel32.dll', 'dword', 'GetLongPathNameW', 'wstr', $sFile, 'wstr', '', 'dword', 4096)
    $test = ObjCreate("Scripting.FileSystemObject")
    Return $test.GetAbsolutePathName($Ret[2])
EndFunc   ;==>_WinAPI_GetLongPathName

It SHOULD work with either folder names or file names

[Kilmatead]

Now that's more interesting - though it does require the object to exist in the first place, else it returns the currently working directory (which is obviously impractical); adding a simple FileExists check before calling the GetLongPathNameW would do the trick in a blunt way, but doing a canonical call first will resolve as much of the path as possible (and return it) to provide the most clarity in case of failure:

Func _WinAPI_GetCaseCorrectLongFileName($sFile)
    $sFile = _WinAPI_PathCanonicalize($sFile)
    If Not FileExists($sFile) Then Return $sFile   
 
    Local $Ret = DllCall('kernel32.dll', 'dword', 'GetLongPathNameW', 'wstr', $sFile, 'wstr', '', 'dword', 4096)
    Local $oTarget = ObjCreate("Scripting.FileSystemObject")
   
    Return $oTarget.GetAbsolutePathName($Ret[2])
EndFunc

 

...thus "C:ExistingExisting....usersNonExisting" returns "c:usersNonExisting" which may not be case-wise sound (obviously, as it doesn't exist) but it certainly returns a close approximation to the requested object, and is safe to use on user-input.

Which brings us down to 4 function-calls (without the canonical it'd be 3), allowing for relative paths and non-existing objects.

Thanks for this - better than my first work-around, and even better than the "old" FileGetLongName which could not deduce relative paths, though at least returned the given path on failure.

[BrewManNH]

If the path doesn't exist, it should set the error condition and return the $sFile parameter. I see no reason to include _WinAPI_PathCanonicalize in the function unless you're not replacing the standard FileGetLongName function, because that function doesn't use it or anything like it. You could use the $oTarget.GetAbsolutePathName to replace the _WinAPI_PathCanonicalize function with your "C:ExistingExisting....usersNonExisting" path string to return the same result.

BTW, none of the functions in the snippet return anything but the parameter and an error if the file or folder doesn't exist.

Also forgot to mention, the above snippet I posted works back to WinXP.

[Kilmatead]

I tacked on the _WinAPI_PathCanonicalize because GetLongPathNameW automatically does the same thing (as does the FileExists call) - I didn't realise that the com's GetAbsolutePathName would do it too - all's the better.  (In fact, a quick check shows that on error GetAbsolutePathName will properly case the part of the canonicalised pathname which does exist, and leave the rest [without truncation], which is perfect.)

Technically none of this was necessary, as my original 5-function mess provided the precise same results (existing/nonexisting) as the old FileGetLongName, but yours reduces that by 1 at least (an extra SetError and FileExists on top of the other two).

The standard FileGetLongName function was more or less irrelevant to me as I only ever used it to "clean" filepaths - at which it worked admirably, until someone decided to neuter it.  So, if I have to replace it anyway, I'll take advantage of building in any extra things that serve a purpose, and canonicalised paths on error fits the bill.

Func _WinAPI_GetCaseCorrectLongFileName($sFile)
    Local $oTarget = ObjCreate("Scripting.FileSystemObject")

    If FileExists($sFile) Then
        Local $Ret = DllCall('kernel32.dll', 'dword', 'GetLongPathNameW', 'wstr', $sFile, 'wstr', '', 'dword', 4096)
        Return $oTarget.GetAbsolutePathName($Ret[2])
    EndIf
    
    Return SetError(1, 0, $oTarget.GetAbsolutePathName($sFile))
EndFunc

Edited June 2, 2014 by Kilmatead

[Ascend4nt]

Brewmanh/Kilmataed, maybe you could submit this as a UDF for inclusion with AutoIt, or at least put it in the Example Scripts forum, as this will probably prove useful to others.  I believe the old FileGetLongName() used a SHGetPathFromIDList() call somewhere..

[guinness]

Examples section please. Also for compatibility use the _WinAPI_* function calls to reduce bloat in a user's script. Thanks.

[Kilmatead]

...for compatibility use the _WinAPI_* function calls to reduce bloat in a user's script.

 

Interestingly enough, there is no _WinAPI_ for GetLongPathNameW defined in the AI library (probably because the native function exists).  Technically that call is superfluous here anyway, as the (otherwise banjaxed) FileGetLongName will serve the same purpose:

Func _GetCaseCorrectLongFileName($sFile)
    If FileExists($sFile) Then
        Local $oTarget = ObjCreate("Scripting.FileSystemObject")
        Return $oTarget.GetAbsolutePathName(FileGetLongName($sFile))
    Else
        Return SetError(1, 0, $sFile)
    EndIf
EndFunc

 

(This thread was not meant to be about a new function, it was just asking why something else went mysteriously "poof"...)

Edited June 5, 2014 by Kilmatead