Path or filename too long

Here is one that would fall nicely into Ask Paul on Friday, but I’m currently frustrated!!!

I’m currently moving user profiles from one partition to another (department changes) and Windows keeps complaining that it can’t read the files, because the path name or filename is too long!

Why the fragging* heck did Windows Server allow the files to be written in the first place, if the names are too fragging long?

So, now, I’m going through nearly 1,900 folders and 11,000 files looking for 350 files whose names were too long to be read, then manually renaming them to something shorter and copying them across!

The source and destination path depths are the same, so it isn’t that they are going to a deeper level that messes them up on the destination, they are “illegal” names where they currently are!

Windows can fire truck** right off!

* fragging: from Babylon 5, to allow characters to express themselves on a show to be aired at prime time.

** fire truck: from Jodi Taylor’s “Doing Time”, to allow the book to be aimed at younger readers, whilst also providing hilarity for older readers.

Conversation 17 comments

  • ianw789

    05 February, 2020 - 11:02 am

    <p>I can't tell you how they were allowed to be created, but I hope you are using a script like this to find the offenders:</p><p><br></p><p><em>$pathToScan = "C:UsersUsername"&nbsp;# The path to scan and the the lengths for (sub-directories will be scanned as well).</em></p><p><em>$lengthThreshold = 205 # Set the threshold for what is to be listed</em></p><p><br></p><p><em>Get-ChildItem -Path $pathToScan -Recurse -Force | Select-Object -Property FullName, @{Name="FullNameLength";Expression={($_.FullName.Length)}} | Sort-Object -Property FullNameLength -Descending | ForEach-Object {</em></p><p><br></p><p><em>&nbsp;&nbsp;&nbsp;$length = $_.FullNameLength&nbsp;&nbsp;&nbsp;</em></p><p><br></p><p><em>&nbsp;&nbsp;&nbsp;if ($length -gt $lengthThreshold ) {</em></p><p><em>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$filePath = $_.FullName</em></p><p><em>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$string = "$length : $filePath"</em></p><p><em>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if ($string )&nbsp;{ Write-Host $string }</em></p><p><em>&nbsp;&nbsp;&nbsp;}</em></p><p><em>}</em></p>

    • ianw789

      05 February, 2020 - 11:05 am

      <blockquote><em><a href="#518324">In reply to ianw789:</a></em></blockquote><p>Well, the back slashes were stripped from the post, but I'm sure you can fix that pathToScan</p>

  • lvthunder

    Premium Member
    05 February, 2020 - 11:09 am

    <p>I've found it's typically done by unzipping files with a long folder structure. Do people access these through a mapped drive? That could be it too. Windows allows P:somelongpathfile.txt where on the server it might be d:Datasharenamesomelongpathfile.txt. It is weird though.</p>

    • wright_is

      Premium Member
      06 February, 2020 - 12:40 am

      <blockquote><em><a href="#518328">In reply to lvthunder:</a></em></blockquote><p>In this case, it is the user using very logn file names over an SMB share.</p>

  • wright_is

    Premium Member
    05 February, 2020 - 1:20 pm

    <p>Thanks to Ian for the suggestion. </p><p>The post is more a cry of why the heck Microsoft haven't sorted this out. It has only been a known bug for, what, 20-25 years…</p>

    • hrlngrv

      Premium Member
      06 February, 2020 - 2:53 pm

      <p><a href="https://www.thurrott.com/forums/support/windows/thread/path-or-filename-too-long#518402&quot; target="_blank"><em>In reply to wright_is:</em></a></p><p>It hasn't been a bug. It's been a known limitation, a design choice.</p><p>I understand how frustrating this is for you because It's happened to me a few times. However, some limits are practical necessities. There's also the chance that even if you restore these files, some Windows applications won't be able to use them directly due to pathnames being too long for the allocated blocks of memory meant to store them.</p><p>How could such files be created in the first place? Ever used SUBST.EXE? For that matter, rename an existing directory with a longer name, and Windows <strong>doesn't</strong> recursively check pathnames for files under that directory. Not so much a question of what's allowed as what's checked.</p>

  • coeus89

    05 February, 2020 - 1:55 pm

    <p><span style="color: rgb(0, 0, 0);">This error drives me crazy. Supposedly they have fixed it but it remains off by default. This is because it can break some old applications that don't support long file names. Good luck. lmk how you make out.</span></p><p><a href="https://lifehacker.com/windows-10-allows-file-names-longer-than-260-characters-1785201032&quot; target="_blank">https://lifehacker.com/windows-10-allows-file-names-longer-than-260-characters-1785201032</a></p&gt;

  • coeus89

    05 February, 2020 - 2:02 pm

    <p>Also to answer your question on how they can exist. One way is mapping a drive in file explorer. This essentially shortens the entire file path to a few characters. So then when you are actually trying to copy the full, unmapped file path, it can be more than the 260 or whatever characters that are allowed and windows will barf.</p>

  • hrlngrv

    Premium Member
    05 February, 2020 - 6:45 pm

    <p>Uh, there's a registry setting which allows for longer pathnames. I'd guess it's enabled by default on Windows file servers but not on client machines.</p><p>HKLM\SYSTEM\CurrentControlSet\Control\FileSystem key, LongPathsEnabled value.</p><p>Also seems to be a group policy setting: Computer Configuration &gt; Administrative Templates &gt; System &gt; Filesystem, which has a policy named <strong>Enable Win32 long paths</strong>.</p><p>Your employer doesn't permit you to perform web searches?</p><p>This comes up on reddit every other week or so.</p>

  • Brett Barbier

    05 February, 2020 - 9:20 pm

    <p>Use robocopy to do this… It supports long paths. </p>

    • coeus89

      06 February, 2020 - 8:06 am

      <blockquote><em><a href="#518544">In reply to Brett_B:</a></em></blockquote><p>Good suggestion. Another option is Beyond Compare. That'll mirror entire directories as well.</p>

    • wright_is

      Premium Member
      06 February, 2020 - 8:39 am

      <blockquote><em><a href="#518544">In reply to Brett_B:</a></em></blockquote><p>Robocopy might copy the files, but it doesn't get around the problem. If the files get corrupted or accidentally deleted, Restoring them won't work, because the path is too long.</p>

      • coeus89

        06 February, 2020 - 1:08 pm

        <blockquote><em><a href="#518587">In reply to wright_is:</a></em></blockquote><p>Try doing the registry change in the link i posed below in a different comment. That should remove the character limit.</p>

  • Patrick3D

    06 February, 2020 - 3:37 pm

    <p>Used to see this a lot with IE Favorites being saved in nested folders with filenames equal to the title of the webpage that included a long subtitle or the first sentence of the page. Mainly scientists with a PHD in chemistry bookmarking white papers and research studies. Another contributing factor were PDFs they were generating by using a "print to PDF" option that generated PDF filenames using the same webpage title.</p>

  • frank gleg

    19 July, 2020 - 7:48 am

    <p>The best suggestion that I can provide for this type of issues is LongPathTool. Best of luck.</p>

  • winner

    19 July, 2020 - 6:34 pm

    <p>You expect a 30 yo OS from Microsoft to actually check things?</p><p><br></p><p>How naive of you!</p>

  • savoli

    08 November, 2020 - 9:39 am

    <p>Long path name is a familiar problem happens when the length is over <span style="color: rgb(60, 64, 67);">260 characters and you can just shorten the paths if you can, but if you have many you can just use the Long Path tool or Gs RichCopy 360, both are powerful with this case, google it</span></p>

Windows Intelligence In Your Inbox

Sign up for our new free newsletter to get three time-saving tips each Friday

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Thurrott © 2024 Thurrott LLC