Implement long path pseudo current directory about yori HOT 4 OPEN

That's what cd -e does:

C:\>cd -?
Chdir 1.80
  Build 20221126

Changes the current directory.

CHDIR [-e] [-license] <directory>

   -e             Change to an escaped long path
C:\>cd -e c:\
\\?\C:\>cd c:\
C:\>

As you noted, this has (bad) compatibility consequences. CMD will interpret these current directories as UNC, which means it automatically change directory to \Windows when launched with one of these active. That breaks all .bat and .cmd scripts. This is why Yori uses prefixed long paths internally for almost everything, except for this, and why I didn't want to silently use prefixed long paths in this specific case. As you say, Yori tools should work, although since this isn't the default operation I haven't tested them in a while.

from yori.

Unfortunately when testing cd -e I still cannot set a long path name as current directory.
If the path name is short enough then it works. and I see the nice \\?\ prefix

For example I get after cd -e:

chdir: could not change directory: \\?\D:\12345678\12345678901234567890123456789
01234567890\1234567890123456789012345678901234567890\123456789012345678901234567
8901234567890\1234567890123456789012345678901234567890\1234567890123456789012345
678901234567890\123456789012345678901234567890\123456789012345678901234567890: T
he filename or extension is too long.

Maybe this is because I use Old windows Server 2003? Windows 7 also gets this problem (I just checked).

I was not sure of what the -e parameter meant because indeed it made no difference when trying to chdir in a long path name. Sorry I forgot to mention that. Or maybe you mean something else?

from yori.

Ouch, you're right, it looks like -e is basically useless.

As far as I can tell:

• Old versions of Windows (pre-10) always allocate current directory using a fixed size buffer that's MAX_PATH in size. This size is actually a value in the PEB, so it's possible to change, which works...except any child process doesn't have the change so if the parent process uses this to force a long path it can't spawn any child until current directory is changed to something shorter.
• As part of the long path changes, Windows 10 attempted to fix this, but the initial attempts didn't account for all characters correctly and weren't correct.
• Newer versions of Windows 10 got this "right" except they only invoke this behavior when long path support is enabled, even though these prefixed paths are conceptually independent of that and are supposed to be an alternative.

Currently the only way I could see this working is to temporarily reset current directory before launching a child, launch the child with debugging enabled, and patch the child's memory to contain the correct current directory and buffer lengths. The problem with doing this is it needs to be recursive - when the child wants to launch another child, that needs to be fixed up too, but CreateProcess fails if the current directory isn't restored before it's called, so the debugger would need to intercept calls to CreateProcess to perform the necessary fixups. Note in particular that the child can be launched either with an explicit current directory or inheriting its parent's current directory, so this requires breaking on CreateProcess, inspecting the arguments and parent state, intercepting the return from CreateProcess (to restore parent state) and applying the saved state to the child on its initial break.

In other words, I'm not sure it's worth pursuing :) Yori already has code to be a debugger in certain cases, but this seems like the most invasive case yet.

from yori.

In other words, I'm not sure it's worth pursuing :) Yori already has code to be a debugger in certain cases, but this seems like the most invasive case yet.

I agree it would be too much trouble.
Current directory was always limited even with UNC because it is legacy from unix/dos and NT api only uses absolute paths. So I guess we are mostly out of luck.

Maybe the cd -s switch could be used to use the short path so that when a path is just a bit too long we could still chdir inside.
This would be a simple workaround, far from perfect of course.
the short path also has the advantage to only have ascii characters and no spaces which is also helpful when invoking non-Unicode and/or non spaces aware programs. I used to use a shortened launcher for several programs that were just stupid.

from yori.