GetTempPath function
Applies to: desktop apps only
Retrieves the path of the directory designated for temporary files.
Syntax
DWORD WINAPI GetTempPath( __in DWORD nBufferLength, __out LPTSTR lpBuffer );
Parameters
- nBufferLength [in]
-
The size of the string buffer identified by lpBuffer, in TCHARs.
- lpBuffer [out]
-
A pointer to a string buffer that receives the null-terminated string specifying the temporary file path. The returned string ends with a backslash, for example, C:\TEMP\.
Return value
If the function succeeds, the return value is the length, in TCHARs, of the string copied to lpBuffer, not including the terminating null character. If the return value is greater than nBufferLength, the return value is the length, in TCHARs, of the buffer required to hold the path.
If the function fails, the return value is zero. To get extended error information, call GetLastError.
Remarks
The GetTempPath function checks for the existence of environment variables in the following order and uses the first path found:
- The path specified by the TMP environment variable.
- The path specified by the TEMP environment variable.
- The path specified by the USERPROFILE environment variable.
- The Windows directory.
Note that the function does not verify that the path exists, nor does it test to see if the current process has any kind of access rights to the path. The GetTempPath function returns the properly formatted string that specifies the fully qualified path based on the environment variable search order as previously specified. The application should verify the existence of the path and adequate access rights to the path prior to any use for file I/O operations.
Symbolic link behavior—If the path points to a symbolic link, the temp path name maintains any symbolic links.
Examples
For an example, see Creating and Using a Temporary File.
Requirements
|
Minimum supported client | Windows XP |
|---|---|
|
Minimum supported server | Windows Server 2003 |
|
Header |
|
|
Library |
|
|
DLL |
|
|
Unicode and ANSI names | GetTempPathW (Unicode) and GetTempPathA (ANSI) |
See also
Send comments about this topic to Microsoft
Build date: 4/17/2012
EDIT: Thanks @Maurits for adding ANSI/UNICODE capability. I turned your annotations into regular code so it looks clean again :)#ifdef _UNICODE
# define tstring std::wstring
#else
# define tstring std::string
#endif
/// <summary>Returns the path to the system's temporary directory</summary>
/// <returns>The full path to the system's temporary directory</returns>
tstring GetTempPath() {
DWORD result = ::GetTempPath(0, _T(""));
if(result == 0)
throw std::runtime_error("Could not get system temp path");
// Allocate temporary buffer. The retured length includes the terminating _T('\0').
// std::vector is guaranteed to be sequential, thus can serve as a buffer that can be written to.
std::vector<TCHAR> tempPath(result);
// If the buffer is large enough, the return value does _not_ include the terminating _T('\0')
result = ::GetTempPath(static_cast<DWORD>(tempPath.size()), &tempPath[0]);
if((result == 0) || (result > tempPath.size()))
throw std::runtime_error("Could not get system temp path");
return tstring(tempPath.begin(), tempPath.begin() + static_cast<std::size_t>(result));
}
- 1/20/2011
- cipactli
- 8/31/2008
- Mark Twain
[Note - this post has been edited based on, and extended by, information in the following post]
Apparently due to the method used by GetTempPathA to translate ANSI strings to UNICODE, this function itself cannot be told that the buffer is greater than 32766 in narrow convention. Attempting to pass a larger value in nBufferLength will result in a failed RtlHeapFree call in ntdll.dll and subsequently cause your application to call DbgBreakPoint in debug compiles and simple close without warning in release compiles.
Example:
// Allocate a 32Ki character buffer, enough to hold even native NT paths.
LPTSTR tempPath = new TCHAR[32767];
::GetTempPath(32767, tempPath); // Will crash in RtlHeapFree
- 5/28/2008
- 6XGate
- 6/29/2008
- Thomas Lee
I have only tested this when compiling an application in MultiByte/Ansi mode, thus it was calling GetTempPathA. This issue may not manifest in Unicode builds since no translation occurs. For the sake of portability, I currently treat even the Unicode version the same way (not specifying sizes greater than 32766) incase I need it to compile and run on 9x/Me systems.
If this has been fixed since Vista SP1 or Server 2008, a note probably should be made about this bug on versions of NT before these. The following link is to posts made by people who have experienced this bug and have made some document of it:
http://www.codeguru.com/forum/archive/index.php/t-401055.html
Hope this helps.
