4

Enabling long path support for my application I have done the following:

  1. Embedded the longPathAware manifest into my application using mt.exe
  2. Ensured that the LongPathsEnabled registry key is set to 1

My application actually started to be able to operate on files located in folders with long paths exceeding the 260 limit, however there exists a problem.

I found no way to start my application where a long path folder is my current working directory. I have tried using cmd, MSYS2, CygWin, explorer

  1. cmd gives the following error:

    The current directory is invalid.

  2. MSYS2 and CygWin both give the following error:

     Error: Current working directory has a path longer than allowed for a Win32 working directory.
 Can't start native Windows application from here.
 bash: /c/myapp: File name too long

  3. explorer does the following:

    • The application icon becomes blank like the one for unknown file types or files with no extensions
    • Double clicking on the application does nothing whatsoever

It is the most common use case for my application to have the files on which the application operates upon in the current working directory. So, given that the current working directory can't exceed that limit means that all of this is kind of useless.

So, my question is: Is there a way to overcome this issue/limitation?

I feel like without having this case working, the whole long paths support doesn't make any sense.

Ayman Salah
  • 1,039
  • 14
  • 35
  • 3
    `SetCurrentDirectoryW` works with long paths, but a long path can't be inherited or set as the initial working directory of a process. [`CreateProcessW`](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) doesn't support it for `lpCurrentDirectory`. Also, a long executable path has to be passed in `lpApplicationName`, which can be a relative path. It can't be passed only in `lpCommandLine` because, without `lpApplicationName`, the API always calls `SearchPathW` with a `MAX_PATH` (260) buffer, even if the command line has an absolute path. – Eryk Sun Sep 15 '20 at 22:33
  • 2
    Even if `CreateProcessW` succeeds, initialization of the process might fail in some scenarios (e.g. SxS activation context IPC between the process and the session server, csrss.exe). And a program has to be mindful to avoid trying to spawn a child process with the working directory as a long path, including implicit inheritance of the working directory (i.e. `lpCurrentDirectory` passed as `NULL`). – Eryk Sun Sep 15 '20 at 22:33
  • 1
    In short, running applications from a long path is possible but limited, clunky, and even buggy (IMO). I wouldn't do it. Use a junction or substitute drive instead. – Eryk Sun Sep 15 '20 at 22:36
  • @ErykSun Thanks for your comments. I have a question. What exactly uses `CreateProcessW`? What exactly spawns my process in case I call my .exe directly from the shell? – Ayman Salah Sep 15 '20 at 22:42
  • 1
    In the case of cmd.exe, it calls `CreateProcessW` directly when running an executable, with or without `start`. It implements its own search for the executable file based on `PATH` and `PATHEXT`, and thus it always passes the executable path in `lpApplicationName` instead of relying on `CreateProcessW` to search for it. But it also tries to inherit the current directory in `lpCurrentDirectory`, which won't work for a long path. The `start` command can override this with an explicit directory via `/D`, or just run the executable with a relative path from a different working directory. – Eryk Sun Sep 15 '20 at 22:52
  • 1
    Some of these comments seem like they would make good answers. – rokejulianlockhart Jul 13 '23 at 15:39

0 Answers0