Bug 17167 – dmd fails to write to file or create directory with more than 248 characters in the path

I saw this while running dub on Windows: Error: Error writing file '..\..\..\..\..\..\AppData\Roaming\dub\packages\taggedalgebraic-0.10.5\taggedalgebraic\.dub\build\library-debug-windows-x86-dmd_2073-20BD164B4B4CA7B99E316352127B8128\taggedalgebraic.lib' If I move the source directory up one directory this stops happening (i.e., dmd would write the output library to '..\..\..\..\..\AppData\Roaming\dub\packages\taggedalgebraic-0.10.5\taggedalgebraic\.dub\build\library-debug-windows-x86-dmd_2073-20BD164B4B4CA7B99E316352127B8128\taggedalgebraic.lib' instead, and successfully)

*** Issue 17888 has been marked as a duplicate of this issue. ***

After some investigation, it seems that dub specifying relative paths makes it more likely to pass the 248 character limit, since Windows first appends the current absolute path to the relative one. This is a known Windows limitation up until an opt-in in Windows 10 to make the problem go away, and otherwise has to be dealt with by calling the Unicode-aware Win32 file APIs.

Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/34f6dedb18fd3d9e6aacac8469f6515da2e77928 Fix issue 17167 - handle long filepaths on Windows https://github.com/dlang/dmd/commit/24ab619f310eed641a60cad492460a0af4e7f0cf Merge pull request #7299 from kaleidicassociates/fix_issue_17167 Fix issue 17167 - handle long filepaths on Windows merged-on-behalf-of: Walter Bright <[email protected]>

Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/34f6dedb18fd3d9e6aacac8469f6515da2e77928 Fix issue 17167 - handle long filepaths on Windows https://github.com/dlang/dmd/commit/24ab619f310eed641a60cad492460a0af4e7f0cf Merge pull request #7299 from kaleidicassociates/fix_issue_17167

Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/c22616ae6ea9c6832d4c261bc957149c2b265a98 Temporarily disable test for issue 17167 on CircleCi https://github.com/dlang/dmd/commit/9b45aa736fd08eed3d20c41c5014f7ff68833bc0 Merge pull request #7486 from wilzbach/circleci-fix Temporarily disable test for issue 17167 on CircleCi merged-on-behalf-of: Petar Kirov <[email protected]>

While trying to find the size of a file which was residing in a path more than 300 character length we were getting the error : The system cannot find the path nor the file exist , so does this fix resolve even this issue. In the below example there are 50-60 sub folders. auto SdFiles = Array!ulong(dirEntries("C:\\Test", SpanMode.depth).map!(a => a.size)). From, Vino.B

@Vino Probably. Try out with dmd at master and see. If not, please file a new issue.

Hi All, As per the issue id 17167 it states that this issue is resolved, but the issue still persist as it tested with DMD32 D Compiler v2.079.1-beta.1 on Windows 2008 R2. so as a temporary solution we have used the UNC path as below Original Path : C:\Test\1\2\3\4\5\6.............\ UNC Path : \\?\C:\Test\1\2\3\4\5\6.............\ Issue : The appending of UNC path is consuming time and memory as it appends to each file's and folders inside the file system. Note: The file system is a windows share from Netapp. May i know when will this be fixed. From, Vino.B

Have you checked this page? https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx I filed this bug because dub was using relative paths and ended up trying to link to ..\..\..\..\..\Users\%USERNAME%\AppData\Roaming\dub\packages\package-name-version\package-name. Before the fix, if the dub path with several .. was too large (which happened often), nothing would work. Now, it does. It's possible that passing in an absolute path is different. I would still say that it's a new bug.

@Geod24 updated dlang/dmd pull request #13828 "Simplify `Module.read` and its interaction with `FileManager`" mentioning this issue: - Windows: Make FileName.exists correctly work with long path While attempting to refactor Module.read not to call 'File.read' twice, test17167 started to fail. The only possible difference was that the first File.read call was conditional on FileName.exists succeeding, while the second call was inconditional. After a bit of research, it turns out that the fix for issue 17167 was apparently missing one key detail (the prefix) to enable long path. This was not visible at the time because the fix for File.read was complete, and so the second attempt would succeed, hiding the issue. https://github.com/dlang/dmd/pull/13828

dlang/dmd pull request #13828 "Simplify `Module.read` and its interaction with `FileManager`" was merged into master: - 8f2a7b139fa06fe3c36c0598ddc114c331d581f6 by Geod24: Windows: Make FileName.exists correctly work with long path While attempting to refactor Module.read not to call 'File.read' twice, test17167 started to fail. The only possible difference was that the first File.read call was conditional on FileName.exists succeeding, while the second call was inconditional. After a bit of research, it turns out that the fix for issue 17167 was apparently missing one key detail (the prefix) to enable long path. This was not visible at the time because the fix for File.read was complete, and so the second attempt would succeed, hiding the issue. This brings into question the correctness / need for toWStringzThen, as it's mostly used for long path, and is still being used in cannonicalName. https://github.com/dlang/dmd/pull/13828