I just discovered our code has places using the temp path in a Long File Name -- Unsafe way, and it never gave us problems before because the GETENV("TEMP"
always returned the Short file name version of the path in the past.
Can someone who runs on WinXP and/or Win2k NTFS with this temp path on the NTFS drive with spaces in the path tell me if those circumstances cause this to return the Long version of the path?
And, on NTFS, is there a "short" version of the path that is guaranteed to not have spaces?
(this function gets the SFN given the LFN, and works on Win2k running on Fat32:
Can someone who runs on WinXP and/or Win2k NTFS with this temp path on the NTFS drive with spaces in the path tell me if those circumstances cause this to return the Long version of the path?
And, on NTFS, is there a "short" version of the path that is guaranteed to not have spaces?
(this function gets the SFN given the LFN, and works on Win2k running on Fat32:
Code:
FUNCTION lfn2sfn
PARAMETERS lcInputString
*FROM: Q192827
* Converts a Win32 long file name to its short file name equivalent
*
* passed: long file name, must already exist for this to work
*
* returns: fully qualified short file name, or empty string
* if error is encountered
*
DECLARE INTEGER GetShortPathName IN Kernel32 STRING @lpszLongPath, ;
STRING @lpszShortPath, INTEGER cchBuffer
DECLARE INTEGER GetLastError IN Win32api
#DEFINE MAX_PATH 255
* buffer to receive converted file name
lcOutputString = SPACE(MAX_PATH)
* length of receiving buffer
llcbOutputString = LEN(lcOutputString)
* if successful, llretval will contain the length of the
* output string
llretval = GetShortPathName(@lcInputString, @lcOutputString,;
llcbOutputString)
IF llretval = 0
* uncomment for error code
* wait window "Error occurred, code is: " + ltrim(str(GetLastError()))
RETURN ""
ENDIF
* truncate it at the length the return value indicates
lcOutputString = LEFT(lcOutputString, llretval)
RETURN lcOutputString