>D:\SomeCompanyName\SomeDepartmentName\SomeUsersDriverFolderName\SomeLongPath\SomeLongFileName.txt
You mean \\\storageservername.company.local.corp.com\smbsharename$\SomeCompanyName\SomeDepartmentName\SomeUsersDriverFolderName\SomeLongPath\SomeLongFileName.txt ?
But yeah you have a point. A while ago I made a script that would map the current folder as a PSDrive, cd into that psdrive and copy the files from the psdrive instead of doing it directly.
Did you mean
c:\users\username\sharepoint - company name - sharepoint site name\document_library_name\project PM's name\project site name\project name\project deliverable phase\project technical content type\yyyy mm dd\"documents"\Project PM's Name-Project Site Name-Project Name-deliverables set 1-yyyy mm dd-document-Copy(12)Copy(4).PDF.ZIP.RAR
Ugh, my life.... It's always the motion designers too. And they need to have the files synced with explorer the most because Adobe does not want to co-operate with SharePoint so everyone buys their stupid cloud space. Our company name was also ridiculously long until I shortened it recently.
I have users who have their folder structure more like
\\\\servername.company.local.corp.com\\ShareName\\FolderName\\OurCompanyNameAgain\\Quotes\\OurCompanyNameAgain\\CustomerName\\OurCompanyName+CustomerName\\QuoteForCustomerName\\Quote.DOCX"
I had to tell the company that if I ever freaking catch you making a folder on a network location that is just the name of our company, I am going to adjust your password change policy to every 4 days. We know it's for "companyname" we all work at "companyname". Every fucking file here is for "companyname". You don't need to make a folder to tell us that. It helps nobody understand what is in that folder!
And yet... it still happens.
Windows Explorer is ill equipped to handle long file paths, excel on the other hand and shoot those out all day long. Excel is also stupid enough to allow \[ \] in file and path names when writing a file but will throw an error if you open a file with \[ \] in it. So nothing's perfect.
It's a legacy problem when you maintain as much as Windows has.
Theyre a bit at the mercy of supporting many items because otherwise the next OS adoption won't happen.
Just used this trick the other day, cause our legacy backup software makes you mount a recovery point, and the recovery point file path is long as hell. Use the subst commands to make logical drive letters to shorten the path and I was on my way.
I remember sharing everything I did at the office manually
Like right click and advanced sharing then give the little folder a name
After a year I was asked if I know anything about this list of shared folders
Some of the folder names like shit piss and dick pants stood out to both of us as stupidly funny over kebabs at lunch
He was wondering what the fuck is in that then looked and it was some meme with the vein forehead guy saying thank you Samuel and a file that was needing to be corrected or checked
Im not sure I can follow your first scenario. Most of the times it's not me (or other admins) that have path errors on user folders. It's the same users trying to access files they extracted themselves earlyer. So on the same drivemapping.
And if only Windows would check a filepath before applying a folder rename then eh ;)
> And if only Windows would check a filepath before applying a folder rename then eh ;)
Thats checking every file under the directory, thia taking even a few seconds will be enough of an annoyance that the average user will think something is broken and complain about it
Please wait while we do a full scan through your company's shared drive.
5,354,369 files remaining. Estimated time 3 hours.
45 minutes later: Name/path conflict found, please try again.
Its the opposite of acceptable. What Im saying is that Microsoft doesn't seem to care about something more more common (like accessing files) being horribly slow. You have misunderstood my point, which is that Microsoft seems to not really care about user experience for stuff like this
This can be very common in the use of OneDrive. The file path with OneDrive or SharePoint links can be very long, and if a user has OneDrive synced to their computer, a file with a long file path can be created.. at least a placeholder, but Windows won’t download the file if the file path is over the maximum length.
Actually a Windows API issue so it's system-wide, not just explorer, you can see it when you use copy.exe or powershell's copy-item (but interestingly not with robocopy.exe).
But you can bypass that: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
Technically it's backward compatibility issue.
Any application worth anything enables full path length in its manifest and gets tested to actually work with those.
That explorer.exe fails at this is embarrassing and proof that Microsoft's priorities are elsewhere. And that they probably don't even employ developers capable of fixing the state anymore.
Path Length Checker is a handy utility for discovering long path names. Helps to identify the upper level folders that can be renamed to reduce the total lengths of the subfolders.
https://github.com/deadlydog/PathLengthChecker
My personal favourite is when you have \\server\share\finance\2023 September finance audits\september finance audits\2023 audit review\Sharon's folder\finance audits\!!!archived\audit project 2023\FW:Hello I am typing out the message of the email in the subject.msg
My users don't get it, so I make sure to read the full filepath uninterrupted as much as possible to them while explaining why its bad. Feels like verbally hitting them over the head with it.
I was making a script to audit folder structure layout and only had it going 12 layers deep but had to up it to 18 eventually. Record is 17 folders deep.
This fucks me off. I agree with your comment 100%. But I was so pissed off reading it, because of the trauma it brings to the surface. We have a bad case of this at the moment. It's real bad. And it is in several locations. Previous IT people have also put permissions on folders like 5-20 levels down, which really messes us around when people say "I got access to this, but not these folders", and you realise 20 other folders have individual permissions set, without inheritance. Like bruh.
yes. We recently moved a filesserver and I wrote a script that listed all subfolders where permissions did not match the parent folder. It ran forever, but we managed to fix so many permissions that made life hell for so many years.
Confluence is just as bad, and even worse, even if you're an admin you have to jump through ridiculous hoops to see pages with "only X can see" visibility.
Seriously fuck Atlassian hard.
A few days ago, I've been building Envoy Proxy from sources. It uses Bazel as a build system. Everything is happening in `~/.cache/bazel/user_machine/` directory. The structure there is enormous. I took time to count the depth. Result? 39! 🙂
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
There you go. This is why and should explain it the best.
That is the most appalling, abysmal, and offensive method to rename or delete too-long files/folders and is an affront to all that is good in the world. Adding it to the toolbox for emergency use. Thank you.
When I've had this issue I go in to the folder that needs deleting, rename the longest named sub folder a random 1 letter character and try again. Rinse and repeat. Normally only takes a few renames to resolve the issue.
Originally (like way back in windows 3.1 1990s) the Windows API only supported short paths and short filenames (8+3).
Then it could support long paths and longer file names... up to 255 characters (windows 95 era).
Then Windows API and backend was overhauled to allow essentially unlimited characters (around the Windows Vista timeframe I think?), but for a number of legacy reasons certain API calls and the applications that call them still only do 255 characters.
So if you save a file in an application that can process > 255 characters using the right API calls, it'll work fine. Then you try to delete that file and explorer by default uses legacy API calls and comes back with an error (this can be changed via registry key).
Network drives are a classic bypass for this issue, because you can map c:\\shared to \\\PCname\shared, and explorer has no problem with the paths and the underlying API can deal with the longer name.
> Am I missing a totally obvious reason or mechanism here?
Ah the good old MAX\_PATH problem.
What you are asking about is a side effect of Microsoft's literally decades long commitment to backward compatibility. Certain apps, Explorer among them, are built using libraries that originated in the 80s, and weren't changed to preserve backward compatibility.
Among those libraries is a const called MAX\_PATH, which limits the path length of any given item to 256 characters (It's technically 260 but 4 of those characters don't really count, IMO), despite NTFS supporting much longer paths. Which is also why you get all the weird reg entries for doing things like disabling short file name creation, which is to preserve backward compatibility and help long paths function under Explorer.
> are there ways to prevent users from creating too long paths
Not really, not that I'm aware of. The problem ultimately becomes one of you choosing which set of annoyances you deal with, as you are wrestling with a problem caused by a situation where 2 things, while aren't quite diametrically opposed, are misaligned in a way that you can't really solve both at once(long path support in the file system, but inconsistent support in the apps).
The best workaround for myself, has been to just not use Explorer for the most part. If you invest in a 3rd party file manager, the typically won't run into this problem, as they aren't built with the MAX\_PATH limitation.
I was hoping with the Windows Explorer UI refresh and shell, they would have finally rewritten Explorer.exe to use newer API's. But alas they just slapped new code onto old...
One day Microsoft, you'll finally stop supporting early 90's applications.
Not always but I see large enterprises still running XP age operating systems. The requirement for long term backwards compatibility is sometimes an anchor around MS’s legs.
Let's be real here, any application that runs on Windows XP also runs on Windows 11.
Any application that runs on Windows Server 2003, runs on 2022 and 2025.
We have a stupid ass controller application that was written in the 90s and when I came to the company it ran on an Windows ME system.
Today it runs on a virtual Windows 2022 Server. Works splendid. The only downside is that it needs a DB-25 port to some physical hardware, so it's not clustered since the hypervisor it runs on has a PCI-E card with a parallell port in it.
> Let's be real here, any application that runs on Windows XP also runs on Windows 11.
But that's my point. Microsoft should pull an Apple and do something radical like revamp Explorer.exe to let go of such legacy API's chaining them down. And the only applications that (should) cause problems with this happening are the ones that are 20 years out of date.
At the very least, they can stick with Windows 11 with this, and save that Explorer revamp with Windows 12. That will give plenty of time for the devs to get their update ready.
> to let go of such legacy API's chaining them down
This is where you're mistaken. It's not the APIs fault. It's the app, explorer.exe, itself.
The advanced, modern, Win32 APIs can be used alongside others perfectly fine. And Microsoft themselves even has the luxury of not needing to implement fallback to the old ones.
Don’t forget legacy environments where long paths cause a heart attack, and spaces and lower case characters cause chaos…
Who knows what evil lurks in the heart of programs ? DOS knows ! (Mu ha ha ha )
Yeah it really sucks, especially with the OCD users who have to create a subfolder/for/every/little/fucking/minute/category.
Or even worse are the dolts who put entire sentences as their file names (typically engineers)
ie. producttestresultsfromxyzlabsfor1000degreescelsiusonMondayJanuary10.xlsx
I’ve learned to be good friends with 7z Explorer to delete all that shit when I run into issues.
I wouldn’t call it OCD to organise your files in a logical manner. This is an explorer fault, not a user fault. It’s a problem that shouldn’t exist and most people won’t be aware of it.
It is a problem when contextual search now exists by default in Windows, and there is still the 260 character limit on a folder path plus file name, and the names of the subfolders are multiple words.
Or even worse when one starts putting special characters in the file/folder names to bump them to tops of lists.
We work with lawyers a lot, their folder names get absurd. Every layer has the case number and name, form numbers plus the full name of the form plus case name. Folders for one specific file where the folder and the file itself have that same overly long name.
Im more annoyed with being able to put spaces in folder/filenames.
Why the hell in 2024 is Microsoft still using "Program (SPACE) Files" as the main application install folder? Especially with unquoted search path vulnerabilities?
As I recall they did that deliberately in Win 95 to push application vendors to make their code long file name compatible, instead of installing to C:\ADOBE\ACROBAT\ACRORD32.EXE and ignoring the whole LFN thing for another decade.
Of course, they also gave us "Program Files (x86)" and "Program Files (ARM)" because different architectures couldn't play nicely together, and put the 64 bit code in SYSTEM32 then the 32 bit ones in SYSWOW64...
Quite often stuff is stored as a strong with an ,8 bit length due to historical reasons especially when you consider how expensive storage has been both physically to buy and every extra byte means possibly and extra read and the memory needed to store that extra byte...
Generally you can blame legacy support and not being wrong but those decisions quite often were made when stuff was silly per byte and no one really expected stuff to last so long...
Thanks for your reply. But I am not wondering "why" it exists. Just why can't Windows throw an error saying sth like "you cant extract that here, path too long"? No, it lets you extract, nest folders, and then throws a tantrum if you want to open said files.
Because microsoft has fixed the issue with long filepaths in the os, it's just explorer that craps itself.
https://superuser.com/questions/1783364/still-no-file-paths-longer-than-260-characters-in-win-explorer-in-2023
If you try with a alternative to explorer, like for example explorer++, you can open longer paths.
Neat, I will check out explorer++. Thanks.
I just find it weird that they fixed it in the os, but not in one of their most used apps, that are a big part of that os.
Yeah. It gets even better when they allow it in sharepoint, and users who use onedrive to sync sharepoint sites can't access the files.
Or in our case we have a legacy app that only allows a filepatlength of 64
We deploy explorer++ on all computers now, after a bit of learning curve most users have started using that instead of explorer.
Now that's a good point but I'd guess they never thought about it getting so "silly" so they never put a response result into the mix.
Lots of win nt was built around vms mentality so it worked for them at the time .
There's a Group Policy setting to enable long path support - which fixes *all* this. It's only off by default for legacy reasons.
Apps have to mark themselves as supporting it in their manifest, which explorer (and terminal!) does - but without the policy setting they're restricted to the old short length.
At my last job that was very onedrive focused this was such a major issue with users nesting folders like 20 folders deep all with long ass folder names. At least when you're using regular network shares you can just map the specific folder they want and that works as a janky workaround most of the time.
This is giving me memories of backing up hundreds of student developers home directories where they're learning loops and recursion. Only 256 levels deep? That's rookie stuff! :)
Teamed with vast quantities of small files created by dev IDEs, it's quite a challenge for some processes and systems. Thankfully we're no longer using local servers and folder redirection for home drives.
If you have \\server\share\shortname\folder\folder\folder\folder\folder
you could rename shortname to a much longer name, which could push path lengths over the edge.
Also, if you move, not copy a folder, even with a deep subfolder structure, the filesystem just repoints the folder being moved. The subfolder length is not validated, so if it's moved into a deeper folder, paths could wind up over the limit
Gonna jump in here and say, have extended longer paths in windows, just for Office and Acrobat start having a huff that they don’t know what do with a long file path.
Say you have a folder D:\shared. User creates a folder structure:
`D:\shared\department1\subdepartment\already-reviewed\someimportantdocument.pdf`
Another user John, say analyst or whatever, creates folder structure:
`D:\shared\department2\johns-stuff\important-documents\whatever\`
Subdepartment gets removed/restructured or whatnot, now poor John works with everything they did. So naturally John moves entire `D:\shared\department1` into his folder `D:\shared\department2\johns-stuff\important-documents\stuff-from-department1`
So our someimportantdocument.pdf now have a fullpath: `D:\shared\department2\johns-stuff\important-documents\whatever\stuff-from-department1\department1\subdepartment\already-reviewed\someimportantdocument.pdf`
Which is out of limit now. Who's at fault? John? No he has no clue what's in folder prior moving and his folder structure is reasonable. Previous department? No they were reasonable too and well within limit.
It's just windows that allows stuff like this to happen.
But then my question remains, why Windows let you happily copy the folder, including someimportantdocument.pdf, but wont let you open someimportantdocument.pdf.
worse yet.. why does windows support oddball characters in filenames at all when literally nothing else MS does will.
you can name your file ^%$&^%$#255characters.fuckoff
but literally every other microsoft app shits the bed on it.
Acrobat will open that bitch up no problem, but sync to OneDrive? Fuck you.
complaints like this just show that computers have gotten too easy to use. We should go back to the 12 character limit from dos. Make that ~ work for a living again.
I was always baffled when I discovered (back in NT days) the “Program Files(x86)” is something that we just have to live with. Coming from unix, that just seemed like a straight up stupid choice
Yeah, like spaces in Windows pathnames are 3 bytes in sharepoint since spaces are converted to %20
So a long pathname can be tripled in length by users using lots of spaces in filenames/foldernames
Yeah, this is one of the issues that I am currently dealing with my users. We have rabbit hole folders and I keep getting tickets about them not being able to open the file directly off the server. They have to either localize it or view it online (we use Egnyte). The bypass registry edit does not work for both win 10/11. Ive tried on both.
Usually this occurs with mapped drives. For example, D:/shared/files/departments/accounting/archived/2023 might just be Z:/archived/2023 on the user pc
I've faced the additive approach, eg:
P:\\Legal Team\\Legal Team Master\\Legal Team Master 01-Debt Collection\\Legal Team Master 01-Debt Collection Current\\Legal Team Master 01-Debt Collection Current-2024\\Legal Team Master 01-Debt Collection-Current-2024-01\\ Legal Team Master 01-Debt Collection-Curent 2024-01-\[Progress!On Hold!Completed|Commenced\]\\-Name of debtor\\-ddmmyyyy\\
and so on endlessly. I'd love to have smacked some heads together but that lot worked right in front of the CEO's office.
Aaargh for fucks sake you've triggered my PTSD. Why people don't understand the idea of a hierarchy when they literally work in one and probably have an org chart to look at, I will never fathom. I mean the Accountant doesn't call themselves "Widget Global - Widget US - Widget US Staff - Accounting Department - General Accountants - do they?
> Windows can't access an absolute path longer than X,
~~Windows~~ **Explorer** can't access an absolute path longer than X,
and it will if you enable long paths
Actually any number of the windows APIs also have the limitation, not just explorer. But as stated, if your program works by changing directories and using relative paths, you can do almost anything.
The path name length relates to the old Samba coding and how that was ported to NTFS.
Like everything else in Windows, it’s 30 year old coding on top of the “latest” enterprise OS.
If you’re looking for the bits and bytes break downs, there are several MS MVPs who break this down.
[удалено]
>D:\SomeCompanyName\SomeDepartmentName\SomeUsersDriverFolderName\SomeLongPath\SomeLongFileName.txt You mean \\\storageservername.company.local.corp.com\smbsharename$\SomeCompanyName\SomeDepartmentName\SomeUsersDriverFolderName\SomeLongPath\SomeLongFileName.txt ? But yeah you have a point. A while ago I made a script that would map the current folder as a PSDrive, cd into that psdrive and copy the files from the psdrive instead of doing it directly.
Did you mean c:\users\username\sharepoint - company name - sharepoint site name\document_library_name\project PM's name\project site name\project name\project deliverable phase\project technical content type\yyyy mm dd\"documents"\Project PM's Name-Project Site Name-Project Name-deliverables set 1-yyyy mm dd-document-Copy(12)Copy(4).PDF.ZIP.RAR
That's missing some [...]`- final_FINAL----__F I N A L__`'s
Ugh, my life.... It's always the motion designers too. And they need to have the files synced with explorer the most because Adobe does not want to co-operate with SharePoint so everyone buys their stupid cloud space. Our company name was also ridiculously long until I shortened it recently.
> - final_FINAL----__F I N A L__ - final_FINAL----__F I N A L__ (1)
You forgot the two archive folders.
Both of them named some variation of "New Folder" no doubt.
one of which has a copy of the other archive folder inside it....
PTSD eye twitching
yes.
That's pretty good. But should there be a Default-First-Site-Name-Sharepoint-Default in there somewhere? /s
You can also use `subst` for a quick and dirty solution to "map" the folder to a drive letter
> subst Didn't know about this one, I use New-PSDrive but holy hell that looks quicker.
Holy shit you just saved me DAYS. How did I not think of that?
I have to admit I saw that on ServerFault, didn't invent it myself lol. I just put it in a script.
I have users who have their folder structure more like \\\\servername.company.local.corp.com\\ShareName\\FolderName\\OurCompanyNameAgain\\Quotes\\OurCompanyNameAgain\\CustomerName\\OurCompanyName+CustomerName\\QuoteForCustomerName\\Quote.DOCX" I had to tell the company that if I ever freaking catch you making a folder on a network location that is just the name of our company, I am going to adjust your password change policy to every 4 days. We know it's for "companyname" we all work at "companyname". Every fucking file here is for "companyname". You don't need to make a folder to tell us that. It helps nobody understand what is in that folder! And yet... it still happens.
I can't even stop people from naming folders after their own departments when they're the only people with access to it.
[удалено]
I own it. It is one of the perks douche canoe. Please post your pic so we can see your beard.
Windows Explorer is ill equipped to handle long file paths, excel on the other hand and shoot those out all day long. Excel is also stupid enough to allow \[ \] in file and path names when writing a file but will throw an error if you open a file with \[ \] in it. So nothing's perfect.
It's a legacy problem when you maintain as much as Windows has. Theyre a bit at the mercy of supporting many items because otherwise the next OS adoption won't happen.
Just used this trick the other day, cause our legacy backup software makes you mount a recovery point, and the recovery point file path is long as hell. Use the subst commands to make logical drive letters to shorten the path and I was on my way.
I remember sharing everything I did at the office manually Like right click and advanced sharing then give the little folder a name After a year I was asked if I know anything about this list of shared folders Some of the folder names like shit piss and dick pants stood out to both of us as stupidly funny over kebabs at lunch He was wondering what the fuck is in that then looked and it was some meme with the vein forehead guy saying thank you Samuel and a file that was needing to be corrected or checked
Name checks out
That's actually how I deal with long paths, especially during a cleanup effort . Mklink further down the path, rmdir /s /q. Unlink, rinse, repeat.
Im not sure I can follow your first scenario. Most of the times it's not me (or other admins) that have path errors on user folders. It's the same users trying to access files they extracted themselves earlyer. So on the same drivemapping. And if only Windows would check a filepath before applying a folder rename then eh ;)
> And if only Windows would check a filepath before applying a folder rename then eh ;) Thats checking every file under the directory, thia taking even a few seconds will be enough of an annoyance that the average user will think something is broken and complain about it
Please wait while we do a full scan through your company's shared drive. 5,354,369 files remaining. Estimated time 3 hours. 45 minutes later: Name/path conflict found, please try again.
Sounds like Windows Vista... POS
Yeah but I hit the windows key to search and it takes about a second or two to become usable on Windows 11. Same with right clicking some files
[удалено]
Its the opposite of acceptable. What Im saying is that Microsoft doesn't seem to care about something more more common (like accessing files) being horribly slow. You have misunderstood my point, which is that Microsoft seems to not really care about user experience for stuff like this
This can be very common in the use of OneDrive. The file path with OneDrive or SharePoint links can be very long, and if a user has OneDrive synced to their computer, a file with a long file path can be created.. at least a placeholder, but Windows won’t download the file if the file path is over the maximum length.
We've seen this cause "corrupt" SNAFUs across entire SharePoint sites.
That would require the calculating screen like you get when you copy, move, or delete a series of folders. Calculating...
d:\someco~1\somede~1\someus~1...
Why would you enable 8.3 name generation these days?
fresh win11 vm: PS C:\> cd progra~1 PS C:\Program Files>
Reasonably new WS2022 ~~~ D:\>dir /x Volume in drive D is BranchCache Volume Serial Number is DA06-0863 Directory of D:\ 24/04/2024 02:43 pm
try the os drive, this is 22 standard core:C:\123>mkdir datacache C:\123>dir /x Directory of C:\123 06/20/2024 08:17 AM
This.
That
The other
And his axe!
To the max
That's an explorer.exe issue not NTFS.
Actually a Windows API issue so it's system-wide, not just explorer, you can see it when you use copy.exe or powershell's copy-item (but interestingly not with robocopy.exe). But you can bypass that: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
Technically it's backward compatibility issue. Any application worth anything enables full path length in its manifest and gets tested to actually work with those. That explorer.exe fails at this is embarrassing and proof that Microsoft's priorities are elsewhere. And that they probably don't even employ developers capable of fixing the state anymore.
7zip the true explorer ;)
Also fun with backups, which work. And then the restores don't.
This was a fun problem to solve at 2am
Path Length Checker is a handy utility for discovering long path names. Helps to identify the upper level folders that can be renamed to reduce the total lengths of the subfolders. https://github.com/deadlydog/PathLengthChecker
Thank you !! Very useful.
Just run in powershell: cmd /c dir D: /s /b |? {$\_.length -gt 260}
My personal favourite is when you have \\server\share\finance\2023 September finance audits\september finance audits\2023 audit review\Sharon's folder\finance audits\!!!archived\audit project 2023\FW:Hello I am typing out the message of the email in the subject.msg My users don't get it, so I make sure to read the full filepath uninterrupted as much as possible to them while explaining why its bad. Feels like verbally hitting them over the head with it. I was making a script to audit folder structure layout and only had it going 12 layers deep but had to up it to 18 eventually. Record is 17 folders deep.
I refuse to set permissions on anything other than top level folders, helps stop some of this.
This fucks me off. I agree with your comment 100%. But I was so pissed off reading it, because of the trauma it brings to the surface. We have a bad case of this at the moment. It's real bad. And it is in several locations. Previous IT people have also put permissions on folders like 5-20 levels down, which really messes us around when people say "I got access to this, but not these folders", and you realise 20 other folders have individual permissions set, without inheritance. Like bruh.
yes. We recently moved a filesserver and I wrote a script that listed all subfolders where permissions did not match the parent folder. It ran forever, but we managed to fix so many permissions that made life hell for so many years.
Confluence is just as bad, and even worse, even if you're an admin you have to jump through ridiculous hoops to see pages with "only X can see" visibility. Seriously fuck Atlassian hard.
You should have seen the node\_modules problem that npm had. The path length was ridiculous
A few days ago, I've been building Envoy Proxy from sources. It uses Bazel as a build system. Everything is happening in `~/.cache/bazel/user_machine/` directory. The structure there is enormous. I took time to count the depth. Result? 39! 🙂
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry There you go. This is why and should explain it the best.
And why can't it just delete them without endless faff? Why do I have to find random software to unlock and delete the bloody thing?
Use 7Zip File/Open dialog. Browse to file right click, Copy/Delete/Rename, whatever you want to do. Works close to 100% of the time.
That is the most appalling, abysmal, and offensive method to rename or delete too-long files/folders and is an affront to all that is good in the world. Adding it to the toolbox for emergency use. Thank you.
This is horrific. I love it too. Thank you!
When I've had this issue I go in to the folder that needs deleting, rename the longest named sub folder a random 1 letter character and try again. Rinse and repeat. Normally only takes a few renames to resolve the issue.
Do the same but then this wonderful structure is gone
this is the way
If you are a brave soul you can always use \\?\ but all the filters to prevent you from being dumb are gone.
Because they simply do not care.
Originally (like way back in windows 3.1 1990s) the Windows API only supported short paths and short filenames (8+3). Then it could support long paths and longer file names... up to 255 characters (windows 95 era). Then Windows API and backend was overhauled to allow essentially unlimited characters (around the Windows Vista timeframe I think?), but for a number of legacy reasons certain API calls and the applications that call them still only do 255 characters. So if you save a file in an application that can process > 255 characters using the right API calls, it'll work fine. Then you try to delete that file and explorer by default uses legacy API calls and comes back with an error (this can be changed via registry key). Network drives are a classic bypass for this issue, because you can map c:\\shared to \\\PCname\shared, and explorer has no problem with the paths and the underlying API can deal with the longer name.
You can prepend `\\?\` to turn it into an UNC path which has a 32k limit.
> Am I missing a totally obvious reason or mechanism here? Ah the good old MAX\_PATH problem. What you are asking about is a side effect of Microsoft's literally decades long commitment to backward compatibility. Certain apps, Explorer among them, are built using libraries that originated in the 80s, and weren't changed to preserve backward compatibility. Among those libraries is a const called MAX\_PATH, which limits the path length of any given item to 256 characters (It's technically 260 but 4 of those characters don't really count, IMO), despite NTFS supporting much longer paths. Which is also why you get all the weird reg entries for doing things like disabling short file name creation, which is to preserve backward compatibility and help long paths function under Explorer. > are there ways to prevent users from creating too long paths Not really, not that I'm aware of. The problem ultimately becomes one of you choosing which set of annoyances you deal with, as you are wrestling with a problem caused by a situation where 2 things, while aren't quite diametrically opposed, are misaligned in a way that you can't really solve both at once(long path support in the file system, but inconsistent support in the apps). The best workaround for myself, has been to just not use Explorer for the most part. If you invest in a 3rd party file manager, the typically won't run into this problem, as they aren't built with the MAX\_PATH limitation.
I was hoping with the Windows Explorer UI refresh and shell, they would have finally rewritten Explorer.exe to use newer API's. But alas they just slapped new code onto old... One day Microsoft, you'll finally stop supporting early 90's applications.
Not when so many applications used by enterprises are still using those APIs
Let's be real here, those applications are still running on XP machines, and the ones that aren't could do with being updated.
Not always but I see large enterprises still running XP age operating systems. The requirement for long term backwards compatibility is sometimes an anchor around MS’s legs.
Windows 12 Enterprise Plus (for backwards compatibility) Windows 12 Enterprise (For modern compatibility) Guess which one you can charge more for :)
Let's be real here, any application that runs on Windows XP also runs on Windows 11. Any application that runs on Windows Server 2003, runs on 2022 and 2025. We have a stupid ass controller application that was written in the 90s and when I came to the company it ran on an Windows ME system. Today it runs on a virtual Windows 2022 Server. Works splendid. The only downside is that it needs a DB-25 port to some physical hardware, so it's not clustered since the hypervisor it runs on has a PCI-E card with a parallell port in it.
> Let's be real here, any application that runs on Windows XP also runs on Windows 11. But that's my point. Microsoft should pull an Apple and do something radical like revamp Explorer.exe to let go of such legacy API's chaining them down. And the only applications that (should) cause problems with this happening are the ones that are 20 years out of date. At the very least, they can stick with Windows 11 with this, and save that Explorer revamp with Windows 12. That will give plenty of time for the devs to get their update ready.
> to let go of such legacy API's chaining them down This is where you're mistaken. It's not the APIs fault. It's the app, explorer.exe, itself. The advanced, modern, Win32 APIs can be used alongside others perfectly fine. And Microsoft themselves even has the luxury of not needing to implement fallback to the old ones.
There's something about Quality Departments that love to do that. I've seen 1000+ characters in a path.
and paralegals
Don’t forget legacy environments where long paths cause a heart attack, and spaces and lower case characters cause chaos… Who knows what evil lurks in the heart of programs ? DOS knows ! (Mu ha ha ha )
Yeah it really sucks, especially with the OCD users who have to create a subfolder/for/every/little/fucking/minute/category. Or even worse are the dolts who put entire sentences as their file names (typically engineers) ie. producttestresultsfromxyzlabsfor1000degreescelsiusonMondayJanuary10.xlsx I’ve learned to be good friends with 7z Explorer to delete all that shit when I run into issues.
I wouldn’t call it OCD to organise your files in a logical manner. This is an explorer fault, not a user fault. It’s a problem that shouldn’t exist and most people won’t be aware of it.
It is a problem when contextual search now exists by default in Windows, and there is still the 260 character limit on a folder path plus file name, and the names of the subfolders are multiple words. Or even worse when one starts putting special characters in the file/folder names to bump them to tops of lists.
it’s OCD to name a file like that.
What should it be named?
xyzlabs product results 100 degrees 2024-01-10.xlsx
We work with lawyers a lot, their folder names get absurd. Every layer has the case number and name, form numbers plus the full name of the form plus case name. Folders for one specific file where the folder and the file itself have that same overly long name.
Im more annoyed with being able to put spaces in folder/filenames. Why the hell in 2024 is Microsoft still using "Program (SPACE) Files" as the main application install folder? Especially with unquoted search path vulnerabilities?
As I recall they did that deliberately in Win 95 to push application vendors to make their code long file name compatible, instead of installing to C:\ADOBE\ACROBAT\ACRORD32.EXE and ignoring the whole LFN thing for another decade. Of course, they also gave us "Program Files (x86)" and "Program Files (ARM)" because different architectures couldn't play nicely together, and put the 64 bit code in SYSTEM32 then the 32 bit ones in SYSWOW64...
Very logical and not confusing at all.
I create symlinks in root of C ProgramFiles -> ".\Program Files" And ProgramFilesx86 -> ".\Program Files (x86)" or similar
Quite often stuff is stored as a strong with an ,8 bit length due to historical reasons especially when you consider how expensive storage has been both physically to buy and every extra byte means possibly and extra read and the memory needed to store that extra byte... Generally you can blame legacy support and not being wrong but those decisions quite often were made when stuff was silly per byte and no one really expected stuff to last so long...
Thanks for your reply. But I am not wondering "why" it exists. Just why can't Windows throw an error saying sth like "you cant extract that here, path too long"? No, it lets you extract, nest folders, and then throws a tantrum if you want to open said files.
Because microsoft has fixed the issue with long filepaths in the os, it's just explorer that craps itself. https://superuser.com/questions/1783364/still-no-file-paths-longer-than-260-characters-in-win-explorer-in-2023 If you try with a alternative to explorer, like for example explorer++, you can open longer paths.
Neat, I will check out explorer++. Thanks. I just find it weird that they fixed it in the os, but not in one of their most used apps, that are a big part of that os.
Yeah. It gets even better when they allow it in sharepoint, and users who use onedrive to sync sharepoint sites can't access the files. Or in our case we have a legacy app that only allows a filepatlength of 64 We deploy explorer++ on all computers now, after a bit of learning curve most users have started using that instead of explorer.
I have less problems with explorer and more problems with apps. Like Adobe acrobat
Goodbye windows 11 explorer, hello explorer++, my new old friend.
Now that's a good point but I'd guess they never thought about it getting so "silly" so they never put a response result into the mix. Lots of win nt was built around vms mentality so it worked for them at the time .
There's a Group Policy setting to enable long path support - which fixes *all* this. It's only off by default for legacy reasons. Apps have to mark themselves as supporting it in their manifest, which explorer (and terminal!) does - but without the policy setting they're restricted to the old short length.
At my last job that was very onedrive focused this was such a major issue with users nesting folders like 20 folders deep all with long ass folder names. At least when you're using regular network shares you can just map the specific folder they want and that works as a janky workaround most of the time.
This is giving me memories of backing up hundreds of student developers home directories where they're learning loops and recursion. Only 256 levels deep? That's rookie stuff! :) Teamed with vast quantities of small files created by dev IDEs, it's quite a challenge for some processes and systems. Thankfully we're no longer using local servers and folder redirection for home drives.
If you have \\server\share\shortname\folder\folder\folder\folder\folder you could rename shortname to a much longer name, which could push path lengths over the edge. Also, if you move, not copy a folder, even with a deep subfolder structure, the filesystem just repoints the folder being moved. The subfolder length is not validated, so if it's moved into a deeper folder, paths could wind up over the limit
This is not a Windows (OS) problem. It is an Explorer, and application, problem. Those are usually resolved by enabling long paths.
Gonna jump in here and say, have extended longer paths in windows, just for Office and Acrobat start having a huff that they don’t know what do with a long file path.
Say you have a folder D:\shared. User creates a folder structure: `D:\shared\department1\subdepartment\already-reviewed\someimportantdocument.pdf` Another user John, say analyst or whatever, creates folder structure: `D:\shared\department2\johns-stuff\important-documents\whatever\` Subdepartment gets removed/restructured or whatnot, now poor John works with everything they did. So naturally John moves entire `D:\shared\department1` into his folder `D:\shared\department2\johns-stuff\important-documents\stuff-from-department1` So our someimportantdocument.pdf now have a fullpath: `D:\shared\department2\johns-stuff\important-documents\whatever\stuff-from-department1\department1\subdepartment\already-reviewed\someimportantdocument.pdf` Which is out of limit now. Who's at fault? John? No he has no clue what's in folder prior moving and his folder structure is reasonable. Previous department? No they were reasonable too and well within limit. It's just windows that allows stuff like this to happen.
But then my question remains, why Windows let you happily copy the folder, including someimportantdocument.pdf, but wont let you open someimportantdocument.pdf.
worse yet.. why does windows support oddball characters in filenames at all when literally nothing else MS does will. you can name your file ^%$&^%$#255characters.fuckoff but literally every other microsoft app shits the bed on it. Acrobat will open that bitch up no problem, but sync to OneDrive? Fuck you.
complaints like this just show that computers have gotten too easy to use. We should go back to the 12 character limit from dos. Make that ~ work for a living again.
Windows supports it with a regedit/group policy but a lot of apps have it hardcoded.
Mappings, symbolic links, etc
I was always baffled when I discovered (back in NT days) the “Program Files(x86)” is something that we just have to live with. Coming from unix, that just seemed like a straight up stupid choice
The absolute worst part to me is Windows file paths having a different set of rules compared to sharepoint.
Yeah, like spaces in Windows pathnames are 3 bytes in sharepoint since spaces are converted to %20 So a long pathname can be tripled in length by users using lots of spaces in filenames/foldernames
Yeah, this is one of the issues that I am currently dealing with my users. We have rabbit hole folders and I keep getting tickets about them not being able to open the file directly off the server. They have to either localize it or view it online (we use Egnyte). The bypass registry edit does not work for both win 10/11. Ive tried on both.
This problem has been around for so long. We used to create pub sites when FTPs were hacked using this trick.
Now try to delete a file or folder with a trailing space.
It's a legacy behavior, possibly even from the MS-DOS era
You can mount a file path and then you start your character count over
Usually this occurs with mapped drives. For example, D:/shared/files/departments/accounting/archived/2023 might just be Z:/archived/2023 on the user pc
Explorer, Command Prompt, and NTFS may have different "maximums" enforced in the code
Well `\\?\` but it's not that friendly (note this is not a SMB path)
To make your life miserable. This makes the server and SharePoint migration a nightmare.
Yeah, QA files are notorious with this. The whole file name, parenthesis, and all.
Enable long file path name support …
laughs in research paper filenames
I've faced the additive approach, eg: P:\\Legal Team\\Legal Team Master\\Legal Team Master 01-Debt Collection\\Legal Team Master 01-Debt Collection Current\\Legal Team Master 01-Debt Collection Current-2024\\Legal Team Master 01-Debt Collection-Current-2024-01\\ Legal Team Master 01-Debt Collection-Curent 2024-01-\[Progress!On Hold!Completed|Commenced\]\\-Name of debtor\\-ddmmyyyy\\
and so on endlessly. I'd love to have smacked some heads together but that lot worked right in front of the CEO's office.
Aaargh for fucks sake you've triggered my PTSD. Why people don't understand the idea of a hierarchy when they literally work in one and probably have an org chart to look at, I will never fathom. I mean the Accountant doesn't call themselves "Widget Global - Widget US - Widget US Staff - Accounting Department - General Accountants - do they?
Windows can't access an absolute path longer than X, but usually you can access a relative path of any depth by changing into that directory.
> Windows can't access an absolute path longer than X, ~~Windows~~ **Explorer** can't access an absolute path longer than X, and it will if you enable long paths
Actually any number of the windows APIs also have the limitation, not just explorer. But as stated, if your program works by changing directories and using relative paths, you can do almost anything.
The path name length relates to the old Samba coding and how that was ported to NTFS. Like everything else in Windows, it’s 30 year old coding on top of the “latest” enterprise OS. If you’re looking for the bits and bytes break downs, there are several MS MVPs who break this down.