0

I got that "The file name(s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a shorter path" error when I was moving documents across folders. I know there are ways to disable that file path length restriction, but those ways just did not work on my laptop.

https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ offers two solutions to get rid of the restriction, the second of which resorts to the use of Group Policy (dpedit.msc). As I am using a Windows 10 Home Edition, the second solution does not work. I tried to install dpedit.msc as instructed here (Windows Starter Edition, Home and Home Premium do not include gpedit, how do I install it?), but for some reason it did not work as demonstrated -- I downloaded that zipped folder and ran the extracted setup.exe file. Following the execution, however, I tried to access gpedit.msc command via RUN as well as START Menu search box, but my laptop failed to locate gpedit.msc.

So I tried the first solution. I looked up regedit and followed everything and changed the value date from 0 to 1. It still did not work, even after I logged off, restarted the computer, and logged back in.

This is giving me so much headache, so I appreciate it if someone can shed some light as to what led to the foregoing issues and how to get rid of the file path restriction.

P.S. I am a tech amateur, so any walk-through or explanation in layman terms would best help, thanks!

Alex Chan
  • 31
  • 1
  • 2
  • @McDonald's I read that post too. The author of that post successfully downloaded dpedit.msc to his/her computer, whereas the download failed on my end. This post is therefore not a duplicate. Please advise, thanks! – Alex Chan Jul 08 '17 at 01:15
  • I mistakenly told you the section for the registry settings for the older versions of Windows 10.... I meant the **Registry Import Enabling Long Paths** section instead. Look at that section of my answer [here](https://superuser.com/questions/1119883/windows-10-enable-ntfs-long-paths-policy-option-missing/1119948#1119948) instead. – Vomit IT - Chunky Mess Style Jul 08 '17 at 04:50
  • did you try to use the [`\\?\\` prefix on the path](https://superuser.com/a/811155/241386)? – phuclv Jul 08 '17 at 17:08

2 Answers2

0

Ok.

Part of the problem is the thinkGeek article. The wording mentions file path, but the screen shot of the error focuses on file name, and late last night I let that cloud my thinking.

@McDonald: the registry edit you suggest in your previous solution doesn't work in 1703.

But I can confirm the Registry edit in the thinkgeek article DOES work. But NTFS maintains a limit on the segment length. So the relative file length still can't exceed 260 characters (this is where thinkgeek was misleading).

I created the following PowerShell script to test this: 

$file_name=""
$directory=""
$file_path=""


# create a directory path of 200 characters. Long but legal.

for ($i=0; $i -lt 200; $i++)
{
    $directory= $directory + "a"
}

write-host "Creating directory"
new-item $directory -itemType directory -force


# add \ so we can use it as a directory below
$directory = $directory + "\"


# create a file name that is 200 chars. Long but legal. 
for ($i=0; $i -lt 200; $i++)
{
    $file_name= $file_name + "b"
}

# make the full path. Now this is 401 chars. 
$file_path= $directory + $file_name


#dump to screen
write-host "full path's length: " $file_path.length


write-host "Creating file with long path..."
new-item $file_path -itemtype file -force

I ran this both Pre and post registry edit.

Pre RegEdit. Errors. No file created.

Post RegEdit: No errors. File Created.

Rob
  • 241
  • 1
  • 5
  • NTFS supports paths over 32,000. – surfasb Jul 08 '17 at 03:59
  • True but the lpMaximumComponentLength value is 255. So if a component of the path exceeds that NTFS won't accept the path? Or is that just an API limitation? – Rob Jul 08 '17 at 04:34
  • 1
    It is an API limitation and app compat decision. There are plenty of programs still out there that break when given a long path as a string. Heck, this week I ran into a browser extension that broke when given a long path. – surfasb Jul 08 '17 at 04:49
  • Bah, I misread your comment. You are correct in that the **filename** cannot be longer than 255. But the question talks about when the **entire path is longer than 255**. And that is the issue. Folders are just filenames with an extra flag that tell the filesystem that it is a folder, so the 255 also applies to **folder names**, but not to the **path length**. – surfasb Jul 08 '17 at 04:58
  • we were looking at this fairly late last night, so no worries! the thinkgeek article is poorly worded and their screen shot of the error focused on a file length. I let that skew my thinking. – Rob Jul 08 '17 at 13:30
  • "the registry edit you suggest in your previous solution doesn't work in 1703" - It absolutely does. Remove the commentary and focus on the answer and I will reverse my downvote which I issued 4 days ago – Ramhound Jul 13 '17 at 03:46
0

thanks for all the inputs and my apology if this is a duplicate. I downloaded OneCommander as instructed here and it worked. OneCommander certainly cannot override/get ride of the file path restriction but it certainly (at least in my case) bypassed it. For your reference, mine is a version 1607, home edition of Windows 10.

Alex Chan
  • 31
  • 1
  • 2