3 ms·
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
by 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 agoIt'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 agoWindows developers have seldom this problem, because we don't do endless nesting of folders.
- int_19h 10y agoPeople 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 agoThey'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.