On Windows, keep the lifetime of relative pathnames as short as possible because of thread-safety issues

Subtitle:

GetFullPathName thread-unsafety because of SetCurrentDirectory isn’t, so derived functions (like Delphi GetDir/ChDir/TPath.GetFullPath, or .NET System.IO.Path.GetFullPath) are not thread-safe either (via The Old New Thing)

A while ago I got a big reminder because of [Wayback] What are these dire multithreading consequences that the GetFullPathName documentation is trying to warn me about? | The Old New Thing

The documentation for the Get­Full­Path­Name function contains this dire warning:

Multithreaded applications and shared library code should not use the GetFullPathName function and should avoid using relative path names. The current directory state written by the SetCurrentDirectory function is stored as a global variable in each process, therefore multithreaded applications cannot reliably use this value without possible data corruption from other threads that may also be reading or setting this value. This limitation also applies to the SetCurrentDirectory and GetCurrentDirectory functions. The exception being when the application is guaranteed to be running in a single thread, for example parsing file names from the command line argument string in the main thread prior to creating any additional threads. Using relative path names in multithreaded applications or shared library code can yield unpredictable results and is not supported.

Boy, this was a trip down memory lane, as subconsciously I was aware of this, but not consciously, so it was great seeing it all written down.

Since most of your Windows applications and services are multi-threaded by now (even if you don’t realise this, a cmd.exe instance already has multiple threads running).

It means that the current directory global process variable can be changed by any thread. Since GetFullPathName relies on this converting relative pathnames to absolute pathnames, it means that over time the conversion might give you different absolute pathnames.

Which means these all are not thread-safe:

• Windows API
  • [Wayback] GetCurrentDirectory function (winbase.h) – Win32 apps | Microsoft Docs
  • [Wayback] SetCurrentDirectory function (winbase.h) – Win32 apps | Microsoft Docs
  • [Wayback] GetFullPathNameA function (fileapi.h) – Win32 apps | Microsoft Docs
•  .NET
  • [Wayback] Directory.GetCurrentDirectory Method (System.IO) | Microsoft Docs
  • [Wayback] Directory.SetCurrentDirectory(String) Method (System.IO) | Microsoft Docs
  • [Wayback] Path.GetFullPath Method (System.IO) | Microsoft Docs
• Delphi XE2 and up:
  • [Wayback] System.IOUtils.TDirectory.GetCurrentDirectory – XE2 API Documentation
  • [Wayback] System.IOUtils.TDirectory.SetCurrentDirectory – XE2 API Documentation
  • [Wayback] System.IOUtils.TPath.GetFullPath – XE2 API Documentation
• Delphi 2010-XE (before namespaces were introduced):
  • [Wayback] SysUtils.SetCurrentDir – RAD Studio VCL Reference
  • [Wayback] IOUtils.TDirectory.SetCurrentDirectory – RAD Studio VCL Reference
  • [Wayback] IOUtils.TPath.GetFullPath – RAD Studio VCL Reference
• Turbo Pascal 3 and up, including any Delphi versions:
  • [Wayback] ChDir Function
  • [Wayback] GetDir Function

Related: Much Turbo Pascal history (via What is a Delphi DCU file? – Stack Overflow)

–jeroen