This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients eryksun, jschwar313, paul.moore, steve.dower, tim.golden, zach.ware
Date 2021-12-15.16:55:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Python 3.9.6 scan_dir returns filenotfound on long paths, 
> but os_walk does not.

This would be surprising. os.walk() has been implemented via os.scandir() since Python 3.5. Do you have a concrete example of the directory structure to test? 

> I see that many people on the internet have said to 
> change the working directory as a work around.  

Changing the working directory is a workaround in Unix, not Windows. Without long-path support, the working directory in Windows is limited to 258 (MAX_PATH - 2) characters.

Without long-path support, the workaround in Windows is to use an extended path, i.e. a Unicode path that's fully-qualified and normalized -- as returned by os.path.abspath() -- and prefixed by "\\\\?\\" or "\\\\?\\UNC\\" (e.g. r"\\?\C:\spam" or r"\\?\UNC\server\share\spam"). This allows the native path length limit of about 32760 characters. Some API functions and applications do not support extended paths. In particular setting an extended path as the working directory is unsupported and buggy, even if long-path support is enabled. But extended paths work fine with most file functions in the os and shutil modules, such as os.scandir(), os.stat(),, shutil.copytree(), and shutil.rmtree().
Date User Action Args
2021-12-15 16:55:42eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, jschwar313
2021-12-15 16:55:42eryksunsetmessageid: <>
2021-12-15 16:55:42eryksunlinkissue46084 messages
2021-12-15 16:55:42eryksuncreate