python os.chdir() Windows Error 2
On 4/1/19, grossmudda at gmail.com <grossmudda at gmail.com> wrote:
These string literals should work if the path exists. You're getting
ERROR_FILE_NOT_FOUND (2), which means that "kerschbaum_input" doesn't
exist. Any other missing directory component would result in
"\U" is a Unicode escape sequence in Python 3 (e.g. "\U0000263A" for
"?") , so "\Us" or "\Un" is a syntax error. In Python 2, this is only
the case for a [u]nicode string literal (e.g. u"C:\Users" is an
error), but we should be using use Unicode for Windows paths even in
Python 2 (at least as much as it permits).
Sequential slashes are allowed in general. The system collapses them
to a single slash. Except more than 2 slashes at the beginning of a
UNC path is always collapsed to 3 slashes, which is an error. That
said, doubling forward slashes in a string literal isn't good form.
It's not escaping anything. It's just two slashes.
> and \\?\c instead of C.
The \\?\ prefix bypasses normalization. For regular Windows
filesystems, this style of path must contain only backslash as the
path separator (no forward slashes) and must be Unicode and fully
qualified. In this case, the final component can use a reserved DOS
device name (e.g. "nul.txt") or end in trailing spaces and/or dots
(e.g. "spam. . ."). That said, using such reserved names is not
recommended when creating new files.
Usually the \\?\ prefix is used to bypass the classic DOS path length
limits (e.g. 247, 258, or 259 characters depending on the context).
However, this is not the case for os.chdir (i.e. WINAPI
SetCurrentDirectoryW). The working directory is hard limited to 258
characters. In Windows 10 it can exceed this limit if long-path
support is enabled in the registry and application (Python 3.6+), but
I don't recommend it because subprocess.Popen (i.e. WINAPI
CreateProcessW) will fail if the inherited working directory exceeds
the 258 character limit.
> I also added the path (in advanced system settings) of the folder.
The PATH environment variable contains directories that are searched
by WINAPI SearchPathW, CreateProcessW, and LoadLibraryExW (by
default). Are you trying to import an extension module that has
FYI, for future reference, it's planned (and already committed) for
Python 3.8 to no longer search the working directory or PATH when
loading dependent DLLs of extension modules. As before, it will look
for DLL dependencies in the directory of the extension module, the
application directory (i.e. location of python.exe), and the System32
directory. But now instead of searching PATH it will use the loader's
secure search path. We'll be able to extend this search path with the
new function os.add_dll_directory, which wraps WINAPI AddDllDirectory.
A similar change is slated for ctypes.CDLL (and derived classes such
as WinDLL), except including the directory of the target DLL in the
search will require using a qualified path, e.g.
ctypes.CDLL('./spam.dll') or ctypes.CDLL('C:/eggs/spam.dll').