4 ms·

Last time I tried to do some web dev on a Windows machine, I had to install bower to install a web component. So I installed npm, then installed bower, then ins

by Zikes 10y ago

Last time I tried to do some web dev on a Windows machine, I had to install bower to install a web component. So I installed npm, then installed bower, then installed the component. When I was finished, I tried to delete bower, but Windows wouldn't let me. It had installed all of its dependencies, which had installed dependencies of their own, each one nested deeper and deeper, node_modules after node_modules, far exceeding 260 characters. I forget what trickery I had to resort to in order to delete that folder. It took a bit of Googling and I had to follow instructions I found on StackOverflow.

Jtsummers 10y ago
On a shared network drive I had to resort to mapping a subdirectory deep within the base directory to a new drive letter to recover data after someone copy/pasted a folder with its own deep-nesting directory structure into it. Would've been nice if Windows wouldn't have let them do that in the first place (given the constraint on file paths).
zxcvcxz 10y ago
Makes you wonder if the people developing windows are even using their own product as a development platform. I imagine they use some unix or unix like platform to program windows and thus the developers themselves rarely run into problems like this, so they become unaccounted for.
- cm3 10y ago
  It's probably more due to having many large product groups (or subsystem groups) that don't cooperate as closely as one would like them to. For example NTFS doesn't have a 260 limit but the userland above and therefore the APIs do.
- pjmlp 10y ago
  Windows developers have seldom this problem, because we don't do endless nesting of folders.
- int_19h 10y ago
  People developing Windows are unlikely to be using npm. And outside of npm (and similar occasional app that uses a very deeply nested directory tree for storage), you don't run into this issue all that often.
- Sanddancer 10y ago
  They're using Windows in development, and the "problem" itself is a compatibility thing to deal with now-antique versions of windows. The underlying kernel can deal considerably longer filenames, it's easy to create paths that can use considerably longer filenames, it's just certain UI portions that can't. MS tries to keep backward compatibility at an almost obsessive level, warts and all. The unfortunate thing about maintaining backward compatibility to an almost obsessive level is that you get artifacts like this limit. While the limit should have been removed some time ago, it became so known, easy to work around, and seldom encountered that it was felt to cause more problems than it solved.
mrweasel 10y ago
To be fair that's a flaw an npm. If the underlying platform has these kinds of limitation, then they really should be taken into account when porting software to that platform. If someone ported software to Linux from Windows, without taking into account that Linux cares about the upper case and lower case letters in filename and paths, then you can't really claim that it's Linux that's broken.
- Too 10y ago
  Later versions of npm install dependencies in a flat structure with duplicates removed, instead of a deep nested tree for each packages sub dependencies sub dependencies sub dependencies and so on... It should help to reduce these problems.
- idbehold 10y ago
  > To be fair that's a flaw an npm. Ummm, not so sure considering all those modules still worked when you'd require them in node. The problem was that you couldn't easily delete those files from the file system. So it is actually the fault of the OS for allowing you to create those files/folders if it wasn't going to also be able to handle deleting them.
sp332 10y ago
There's a whole different API. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... But it pretty much comes down to adding \\?\ to the front of your path.
pjmlp 10y ago
That is a npm issue. I do web development on Windows using Java and .NET stacks, never had the problem.

by Zikes 10y ago

Jtsummers 10y ago

On a shared network drive I had to resort to mapping a subdirectory deep within the base directory to a new drive letter to recover data after someone copy/pasted a folder with its own deep-nesting directory structure into it. Would've been nice if Windows wouldn't have let them do that in the first place (given the constraint on file paths).

zxcvcxz 10y ago

Makes you wonder if the people developing windows are even using their own product as a development platform. I imagine they use some unix or unix like platform to program windows and thus the developers themselves rarely run into problems like this, so they become unaccounted for.

cm3 10y ago
It's probably more due to having many large product groups (or subsystem groups) that don't cooperate as closely as one would like them to. For example NTFS doesn't have a 260 limit but the userland above and therefore the APIs do.
pjmlp 10y ago
Windows developers have seldom this problem, because we don't do endless nesting of folders.
int_19h 10y ago
People developing Windows are unlikely to be using npm. And outside of npm (and similar occasional app that uses a very deeply nested directory tree for storage), you don't run into this issue all that often.
Sanddancer 10y ago
They're using Windows in development, and the "problem" itself is a compatibility thing to deal with now-antique versions of windows. The underlying kernel can deal considerably longer filenames, it's easy to create paths that can use considerably longer filenames, it's just certain UI portions that can't. MS tries to keep backward compatibility at an almost obsessive level, warts and all. The unfortunate thing about maintaining backward compatibility to an almost obsessive level is that you get artifacts like this limit. While the limit should have been removed some time ago, it became so known, easy to work around, and seldom encountered that it was felt to cause more problems than it solved.

mrweasel 10y ago

To be fair that's a flaw an npm. If the underlying platform has these kinds of limitation, then they really should be taken into account when porting software to that platform. If someone ported software to Linux from Windows, without taking into account that Linux cares about the upper case and lower case letters in filename and paths, then you can't really claim that it's Linux that's broken.

Too 10y ago
Later versions of npm install dependencies in a flat structure with duplicates removed, instead of a deep nested tree for each packages sub dependencies sub dependencies sub dependencies and so on... It should help to reduce these problems.
idbehold 10y ago
> To be fair that's a flaw an npm. Ummm, not so sure considering all those modules still worked when you'd require them in node. The problem was that you couldn't easily delete those files from the file system. So it is actually the fault of the OS for allowing you to create those files/folders if it wasn't going to also be able to handle deleting them.

sp332 10y ago

There's a whole different API. https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3... But it pretty much comes down to adding \\?\ to the front of your path.

pjmlp 10y ago

That is a npm issue. I do web development on Windows using Java and .NET stacks, never had the problem.