Longpathsenabled windows server 2012

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов Pyatilistnik.org. В прошлый раз мы с вами разобрали возможности утилиты PING, рассмотрели как ее применять на практике. В сегодняшней публикации я вам покажу, как устраняется боль и печаль в операционных системах Windows, я говорю про длинные пути, в своей практике я очень часто встречал жалобы «Слишком длинный целевой путь» или «Слишком длинный конечный путь«, то же самое вы можете встретить и при удалении. Ниже я покажу, как выкручиваться из данной ситуации.

Описание проблемы длинных путей

Раньше имена файлов в Windows ограничивались форматом 8.3 — всего восемь символов для имени файла и три для расширения. С появлением Windows 95 Microsoft сняла этот предел и позволила использовать гораздо более длинные имена.

Тем не менее, файловая система Windows по-прежнему накладывает некоторые ограничения, например, какие символы могут использоваться в именах файлов и общую длину путей. Некоторое время максимальная длина пути составляла 260 символов, но с появлением Windows 10, часть ограничений начала потихоньку уходить, например для приложений и появилась возможность отключить проверку MAX_PATH и использовать длинные пути без префикса \\?\.

Что интересно, значение в 260 символов обусловлено значением MAX_PATH Win32 API. У файловой системы NTFS максимальная длина пути ″немного″ больше и составляет 32767 символа. Для обхода ограничений Win32 API некоторые приложения используют формат UNC, указывая абсолютный путь с префиксом \\?\, например так:

Большинство людей может и не столкнуться с ней, а вот почти каждый системный администратор обязательно это увидит. Тут все дело в том, что в большинстве организаций есть свои сетевые файловые ресурсы, через которые пользователи производят обмен и работу с документами. В какой-то момент люди могут создать такой путь, который будет 258 или 260 символов, попытаются туда скопировать файл, а им выдастся ошибка:

Тоже самое при копировании в папку, так же выскакивает «Слишком длинный целевой путь».

Вот ошибка при извлечении архива в сетевую папку:

Методы снимающие ограничения на длину пути в Windows

• Через групповую или локальную политику Windows (Применимо только к Windows 10 и Windows Server 2016 и выше)
• Через реестр Windows (Применимо только к Windows 10 и Windows Server 2016 и выше)
• Через сторонние утилиты 7-Zip, Far, TotalCommander (Применимо ко всем версиям Windows)
• Использование силинков (символических ссылок) (Применимо ко всем версиям Windows)
• Через сетевой диск, для укорачивания пути
• Утилиты xcopy, robocopy

Нюансы длинных путей в приложениях

Есть один нюанс. Этот новый параметр (имеется ввиду та политика и ключ реестра) не обязательно будет работать со всеми существующими приложениями, но он будет работать с большинством. В частности, любые современные приложения должны работать нормально, как и все 64-битные приложения. Старые 32-разрядные приложения должны быть применимы для работы, что на самом деле просто означает, что разработчик указал в файле манифеста приложения, что приложение поддерживает более длинные пути. Большинство популярных 32-битных приложений не должно вызывать проблем. Тем не менее, вы ничем не рискуете, пробуя настройку. Если приложение не работает, единственное, что произойдет, это то, что оно не сможет открывать или сохранять файлы, сохраненные в местах, где полный путь превышает 260 символов.

Если вы разработчик, то чтобы ваше приложение имело возможность работать с длинными путями Windows, в манифесте обязательно указывайте следующие настройки:

Как в Windows 10 отключить ограничение на длину пути в 260 символов через политику

Чем примечателен данный метод, так это тем, что неподготовленных пользователей он не вынуждает выполнять команды или производить правку реестра, тут все в графическом виде. Так же если у вас есть домен Active Directory и вы хотите массово убрать ошибки «Слишком длинный целевой путь» или «Слишком длинный конечный путь» в приложениях и запретить им проверять MAX_PATH и использовать длинные пути без префикса \\?\, то групповые политики вам это помогут.

Покажу для начала, как делать через локальную политику, открываете окно «Выполнить» в котором пишите gpedit.msc.

Далее идем по пути:

Найдите тут параметр «Включить длинные пути Win32 (Enable Win32 long paths)«, по умолчанию он отключен, и я честно не понимаю почему. Активируйте его.

Как я писал выше, в проводнике это не даст ни каких эффектов, поэтому вы все так же будите получать ошибку при копировании, создании, удалении «Слишком длинный целевой путь» или «Слишком длинный конечный путь«. Ниже я покажу, что делать если нужно что-то там удалить или изменить. Данное ограничение в длине пути теперь не подхватиться на лету всеми приложениями, потребуется перезагрузка.

Включение поддержки длинных путей через реестр

Данный метод ни чуть не сложнее предыдущего и делает все то же самое, включает поддержку длинных путей свыше 256 символов для приложений Windows. Когда вы что-то меняете через редактор политик, по сути меняются настройки в реестре, это нужно помнить и знать. Сейчас я вам покажу какой ключ меняется. Откройте редактор реестра Windows. Перейдите в раздел:

тут вам необходимо найти параметр LongPathEnabled, которому для активации поддержки длинных путей и изменения ограничений в MAX_PATH, нужно задать значение «1». Тут потребуется перезагрузка.

Все что вам нужно, это распаковать zip-архив и запустить нужный файл активации, потом так же перезагрузиться, так как у вас будет создан нужный ключ реестра, без необходимости лезть в реестр самостоятельно.

Еще вы можете сделать такую поддержку и для конкретного пользователя по пути:

Если там нет ключа LongPathsEnabled, то создайте его, тип DWORD (32 бита) и значение 1.

Как в Windows 10 отключить ограничение на длину пути в 260 символов через PowerShell

Не все люди готовы копаться в редакторах и реестрах, им нужно быстрое решение, одним из таких является PowerShell. В оболочке выполните команду для активации параметра «Включить длинные пути Win32 (LongPathEnabled)». Не забываем перезагрузить систему.

Как удалять, копировать, переносить файлы и папки при ошибке с длинными путями

Разобравшись с тем, как отключить проверку MAX_PATH в приложениях, давайте теперь поймем и научимся решать проблему длинных путей на файловых шарах и просто в проводнике. Классическая ситуация, когда пользователь попытался перенести свой файл или удалить его, создать папку и так далее, и он получает ошибку с пресловутыми длинными путями. Он просит разобраться вас и тут начинаются танцы с бубнами, вы просите его либо переименовать часть пути, или попросить его произвести действия в другом расположении, или просто забить, сказав, что виновата Windows со своими ограничениями, но мы же с вами профессионалы и инженеры, поэтому должны уметь выходить из таких ситуаций.

Как в Windows 10 отключить ограничение на длину пути в 260 символов через командную строку

Запустите командную строку в режиме администратора и введите:

Обход ограничений длинных путей через 7zFM

Наверняка многие знают архиватор 7Zip, но мало кто пользуется его файловым менеджером 7zFM.exe, а зря именно он может вам помочь в ситуации с сообщением «Слишком длинный целевой путь» или «Слишком длинный конечный путь». Вот у меня есть тестовая директория, у которой уже есть 260 символов в пути, и я не могу там создавать новую папку.

Откройте 7zFM.exe и перейдите в нем в конечную папку вашего пути.

Для создания новой папки нажмите клавишу F7.

Задайте необходимое вам имя, в моем примере это будет «БОльше 260 Microsot«.

В результате у нас создалась новая папка и заметьте 7zFM не ругнулся на наличие длинных путей, он их игнорирует просто и все.

Проверяем, что директория доступна через проводник Windows.

Все прекрасно отображается. Теперь я думаю вы легко сможете переносить, копировать, удалять файлы через 7zFM, когда вам проводник Windows ругается на наличие длинных путей.

Как обойти ограничение длинных путей через символьную ссылку

Такой трюк мы с вами уже проделывали, когда нужно было переносить IMAP профиль у Outlook. Смысл в том, что создается файл в нужном вам месте, и этот файл это просто ярлык ссылающийся на нужный вам файл или папку, после этого путь сокращается и вы можете удалять или создавать все что вам нужно. Откройте командную строку, далее вам нужно иметь два составляющих:

• Путь где будет лежать файл символической ссылки — в моем примере C:\короткий путь
• Длинный путь — C:\Share\WINDOW

Нам поможет команда mklink, где ключ /D создает ссылку на каталог

Longpathsenabled windows server 2012

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I know that the character limit is 256, however I ran into an issue that has me confused.

I have a Windows Server 2012 R2 Server with a Shared Folder on F:\ called FileShare. FileShare has a subfolder Users. I mapped a drive to my user folder \\Server\FileShare\Users\abcdefg to O:\ on a Windows 7 Workstation. On the O: drive, I created a txt file with a file name that was 251 characters in length (that was the max before it wouldn’t let me type anymore). I received no errors. Once you ad the «.txt», the 255 character limit is reached.

Now comes the confusing part. When I go on the file server, the actual file path is 277 characters because the file resides on F:\FileShare\Users\abcdefg. When I right click on the file I only get Open, Print, Edit, Open with, and Send to as menu options. I can not delete nor shift+delete the file from the file server itself.

Why was I allowed to create a file name that long in the first place? How can I remove a file like this from the server itself?

Windows Server 2012 R2 Standard “Enable NTFS long paths policy” option missing

A similar problem as in Windows 10 occurs in Windows Server 2012 R2 Standard. The Enable NTFS long paths policy is neither in Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem nor in . > Filesystem > NTFS (see screenshots). Is this option available for Windows Server 2012 R2 Standard?

I need this option in order to restore deleted files with too long names within a still existing subfolder. Moving this subfolder to another location i.e. shorter path does not solve the problem as the deleted files will not be restorable from that new location.

The answer for how to delete too-long-names and similar threads are no options as I was unfortunately able to delete the files, however, I can not restore them.

1 Answer 1

Is this option available for Windows Server 2012 R2 Standard?

Windows Server 2012 R2 does not support paths longer than 260 characters. Windows Server 2012 R2 is based on Windows 8.1 not Windows 10 version 1607+ , and the option you are asking about is only a feature of Windows 10 version 1607+ .

I need this option in order to restore deleted files with too long names within a still existing subfolder.

What you want is not possible with the operating system you are using. Windows Server 2012 R2 does not support this option. If you absolutely must have this option you would have to upgrade to Windows Server 2016 or greater.

Windows Server 2012R2 Error «file path is too long»

Question, i am migrating our old 2003 file server to win 2012R2 but got the file path is too long for the destination drive error, how can i get around this?

It may be worth taking a look at Richcopy. It’s newer and has a GUI.

There are some quirks with Richcopy, won’t save settings IIRC. I found it to be a PITA.

I much prefer Robocopy. Once you have some basic knowledge it’s not that difficult.

If you’re running Windows 7 or newer then version here from 2012:

The help desk software for IT. Free.

Track users’ IT needs, easily, and with only the features you need.

62 Replies

could you elaborate a little more?

You can use «Net Use» or «Subst» to assign a long path to a drive letter and choke up on the path to manually do stuff.

You can use robocopy to copy, because it supports long path.

You can use robocopy to delete a directory tree that is too long.

But, to offer a firm suggestion, we need more info like Bill said.

Then generally happens when your path changes. Maybe your old file server was called \\FileServer, but you decided to go with dfs and now the file path is \\reallylongdomainname.com\namspace\target. You’ve increased the path by several characters, and now anything on the old server that was close to the 256 character path limit, goes over 256.

DataGuys is an IT service provider.

2012 has 8dot3 long filename support turned off by default.

you need to turn it on for the drive run the following command and report back your findings

fsutil behavior set disable8dot3 0

I was copying over the files from one server to the other and got the error stating that the file path is too long for the destination drive, these are user files with folders within folders within folders. i know windows has a character limitation but how can i get around this? I cant really change the names of the folders or files

When you copy them over, are you copying them to a sub-folder, thereby adding to the length?

Your going to have to rename or restructure to keep your paths below 256. You can get the files over to the new server with robocopy. But once there, no one will be able to use the deep files, because of the path limit. So you’ll have to use Subst to choke up on the directory path. Say the path is over 256 characters like (. represents a lot more path)

d:\shares\long\path\. \more path\some more path\folder naming nonsense\blah.txt

Subst z: d:\shares\long\path\. \

then you do whatever you have to do using z:

Your going to have to rename or restructure to keep your paths below 256. You can get the files over to the new server with robocopy. But once there, no one will be able to use the deep files, because of the path limit. So you’ll have to use Subst to choke up on the directory path. Say the path is over 256 characters like (. represents a lot more path)

d:\shares\long\path\. \more path\some more path\folder naming nonsense\blah.txt

Subst z: d:\shares\long\path\. \

then you do whatever you have to do using z:

2012 has 8dot3 long filename support turned off by default.

you need to turn it on for the drive run the following command and report back your findings

fsutil behavior set disable8dot3 0

If you want file names to have a

in them, use this method:

Really, you need to use shorter paths or consider the naming scheme currently being used.

Here’s a better explanation of what is going on here:

Your going to have to rename or restructure to keep your paths below 256. You can get the files over to the new server with robocopy. But once there, no one will be able to use the deep files, because of the path limit. So you’ll have to use Subst to choke up on the directory path. Say the path is over 256 characters like (. represents a lot more path)

d:\shares\long\path\. \more path\some more path\folder naming nonsense\blah.txt

Subst z: d:\shares\long\path\. \

then you do whatever you have to do using z:

But why does it work on win 2003 with no problem and it doesnt on win 2012. I am copying to the root of the drive just as it was on the other server.

Because the NTFS file system can handle longer paths, it’s Explorer and other things that have issues. Do as stated above by cduff and you can copy these long folders to your new server, intact. They’ll be just as long and cause trouble in the future if you try to copy them, but they’ll work just fine in your shares.

2012 has 8dot3 long filename support turned off by default.

you need to turn it on for the drive run the following command and report back your findings

fsutil behavior set disable8dot3 0

If you want file names to have a

in them, use this method:

Really, you need to use shorter paths or consider the naming scheme currently being used.

Wait, that’s not quite right. cduff said you can copy using subst and that’s correct. But the files and folders will be completely accessible, as they now are, via shares.

Your going to have to rename or restructure to keep your paths below 256. You can get the files over to the new server with robocopy. But once there, no one will be able to use the deep files, because of the path limit. So you’ll have to use Subst to choke up on the directory path. Say the path is over 256 characters like (. represents a lot more path)

d:\shares\long\path\. \more path\some more path\folder naming nonsense\blah.txt

Subst z: d:\shares\long\path\. \

then you do whatever you have to do using z:

But why does it work on win 2003 with no problem and it doesnt on win 2012. I am copying to the root of the drive just as it was on the other server.

It was working on 2003 for typical users because they were not working in the root directory like you are.
If you map a drive on the 2012 server to a user folder, such as \\SERVER2012\USERS\JohnDoe, then robocopy from the same folder in 2003, it will work just fine.
That’s what everyone is telling you here.

Your going to have to rename or restructure to keep your paths below 256. You can get the files over to the new server with robocopy. But once there, no one will be able to use the deep files, because of the path limit. So you’ll have to use Subst to choke up on the directory path. Say the path is over 256 characters like (. represents a lot more path)

d:\shares\long\path\. \more path\some more path\folder naming nonsense\blah.txt

Subst z: d:\shares\long\path\. \

then you do whatever you have to do using z:

But why does it work on win 2003 with no problem and it doesnt on win 2012. I am copying to the root of the drive just as it was on the other server.

Are the paths the same length? The server names? Share names? Paths cannot be longer than 256. Say your 2003 server name is bob and your new server name is john. john is 1 character longer than bob. So if you have a working path on bob that was 256 characters exactly and copied it to john, it would be 257, you’ll get a path too long error.

2012 has 8dot3 long filename support turned off by default.

you need to turn it on for the drive run the following command and report back your findings

fsutil behavior set disable8dot3 0

If you want file names to have a

in them, use this method:

Really, you need to use shorter paths or consider the naming scheme currently being used.

Ok i will try this over the weekend, but the reason why i cant change or alter these are because they are user files and hr files, altering these may cause a problem. I will have to dig in and find which particular folder this happened in

2012 has 8dot3 long filename support turned off by default.

you need to turn it on for the drive run the following command and report back your findings

fsutil behavior set disable8dot3 0

If you want file names to have a

in them, use this method:

Really, you need to use shorter paths or consider the naming scheme currently being used.

Ok i will try this over the weekend, but the reason why i cant change or alter these are because they are user files and hr files, altering these may cause a problem. I will have to dig in and find which particular folder this happened in

Just reiterating CDuff’s suggestion will work. But in the long term you need to use shorter paths and consider how things are being named. I see this problem a lot with engineering documents where 15 underscores are added for no reason to a file name and then buried in folder after folder after folder.

Are the paths the same length? The server names? Share names? Paths cannot be longer than 256. Say your 2003 server name is bob and your new server name is john. john is 1 character longer than bob. So if you have a working path on bob that was 256 characters exactly and copyed it to john, it would be 257, you’ll get a path too long error.

2012 has 8dot3 long filename support turned off by default.

you need to turn it on for the drive run the following command and report back your findings

fsutil behavior set disable8dot3 0

If you want file names to have a

in them, use this method:

Really, you need to use shorter paths or consider the naming scheme currently being used.

Ok i will try this over the weekend, but the reason why i cant change or alter these are because they are user files and hr files, altering these may cause a problem. I will have to dig in and find which particular folder this happened in

LGM was telling you NOT to do that.

I should have added /sarcasm.

Are the paths the same length? The server names? Share names? Paths cannot be longer than 256. Say your 2003 server name is bob and your new server name is john. john is 1 character longer than bob. So if you have a working path on bob that was 256 characters exactly and copyed it to john, it would be 257, you’ll get a path too long error.

That’s not true. Paths can be much, much longer than 256. NTFS length limit is some insane number. The problem is that many programs can’t access folders when you go deeper than 256 so you run into trouble, unless you are working via a share or a subst.

I was just being general. I did mention that robocopy supports long path and could be used to copy the long paths. I know and agree that the 256 character path limit is imposed by the Win32 API and not NTFS, and as such any tools that use the long path API or have direct NTFS access are not limited to this. But he was asking why it wouldn’t work and this is because of the 256 character Win32 API limit.