Hi, On 2015-04-28 17:33, Doug Kelly wrote: > If you're able to do everything through the Unicode Win32 APIs, you can reach 65535 characters, assuming the filesystem supports it (NTFS does, FAT32 would not, for example). I recall there being one function (possibly thinking of mktemp) that couldn't properly handle the long paths, but I believe that was it. IIRC the MSDN documentation of at least one of the directory-related functions was not quite guaranteeing that it would support long paths with all Windows versions, either. > Other apps may or may not handle the longer paths well; the core.longpaths > switch may prevent mishaps in more than just Explorer, but the downside isn't > disaster always either -- for example, Explorer just refuses to browse > to that path. The problem comes from a different angle, though: I had *a lot* of fun when working on the tests for the `core.longpaths` feature because our very own `rm.exe` would not handle the long paths. As a consequence, quite a few tests failed to remove the trash directories of previous, failed test runs. In such a case you will have to resort to use different tools than you are used to, and *that* is the reason why we do not enable that feature by default. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html