4 ms·
It makes sense for this be opt-in, but I'd like to know how they want to achieve compatibility with apps that didn't adapt and are given such a file.
by cm3 10y ago
It makes sense for this be opt-in, but I'd like to know how they want to achieve compatibility with apps that didn't adapt and are given such a file.
- rincebrain 10y agoEventually, one presumes they'll have a flag in the Compatibility tab for applications, "does not believe in long paths", rather than an opt-in/opt-out. It'll be great - like the 8.3 transition all over again!
- Arnavion 10y ago>Application manifests, which are mostly resources included in every executable file for compatibility reasons, will require apps to add a mention of this new policy, thus making sure that they support a path longer than 260 characters. So if it doesn't have the manifest entry, the program will be assumed to not handle longer paths.
- cm3 10y agoThis sounds reasonable. Case in point are other features which required a manifest with the right entries.
- monocasa 10y agoYeah, I'm not surprised; that's generally how they handle these sorts of things. See /LARGEADDRESSAWARE.
- rincebrain 10y agoThank you, I had not noticed that in the original article, only the registry key. That puzzles me, then - why have a registry key to toggle being able to manifest that at all?
- WorldMaker 10y agoSo that Group Policy can turn it off. For instance, an Enterprise doesn't want anyone using super long paths, even if software is manifested to handle it, because some of their NTFS drives are secretly NetWare shares of FAT volumes still and things will go wonky. The more interesting question is why doesn't this build default that registry key to On in this Build. My presumption here is that the Win32 subsystem changes are possibly significant and there are some backwards compatibility concerns and so this is "feature flagged" until it's been tested more in labs/real world exposure.
- unlinker 10y agoI guess they simply won't. Apps that don't adapt can't open the file. Period.
- cm3 10y agoGiven how drastically Microsoft changed in the last couple years, I wouldn't be surprised if they distanced themselves from the level of compatibility guarantees they issued in the past. EDIT: I don't think it would go down well, if some files cannot be opened in all applications only because of the path. I mean, Windows is the biggest enviroment for the most diverse set of desktop applications right now, so refusing to open files because your app doesn't support the path sounds unreasonable but I cannot think of a solution myself. Thus I'd like to know how they're approaching this.
- unlinker 10y agoI'd say they will not enable that policy by default, at least for a very long time.
- ashmud 10y agoPossibly a junction-like mapping into the "physical" position in the MFT. Perhaps something like "\\?\$MFT\positioninmft\possiblyshortenedfilename.ext". Somewhat similar to the various mappings for 32-bit programs running on 64-bit Windows.