Replies: 7 comments
-
Hi ecovio1, thanks for the feedback! @ptorr-msft do you have any thoughts on long path awareness? |
Beta Was this translation helpful? Give feedback.
-
Thanks for the suggestion (and your interest in long paths), but as-written this is not aligned with the broad goals of Reunion because we want to allow incremental adoption of Project Reunion features in existing apps. If an existing app just wants to (e.g.) use a new WinUI control, they shouldn't have to completely rewrite their file handling code (and / or wait until the libraries they're using get updated) to deal with 32k paths. If you have specific suggestions around how to make it easier to embrace long paths, they would be good proposals. (I'll also note for completeness that the entire long-path feature is off by default so there is no immediate benefit for users). |
Beta Was this translation helpful? Give feedback.
-
for that comparatively smaller change, forcing to use anything other than that will be headache, yes sure. I understand what you are saying. that's fine if all apps not require it. but but , judging on the past changes of most win32 apps since they were created, I suspect if that will be the case here.
should've been "for Existing apps and libraries without buffer overrun" . accessing long paths using existing libraries will require abstraction and innovation.
a cumulative update can fix/overwrite that going downlevel to 1809 . the rule of nature is : if that innovation requires a change in the core, changes/innovations must must start at some point. this was the point of the proposal. |
Beta Was this translation helpful? Give feedback.
-
There is a very good reason why it's off by default -- it would cause confusion for customers due to almost-non-existent support amongst consumer apps. Imagine a person who copies a photo into a long path and then is confused because their photo-editing app can't find it. Even Windows Explorer doesn't support long paths today, at least in part because of the ecosystem of 3rd-party add-ins that cannot handle long paths either. The primary users of the feature today are developers, who generally know how to deal with these problems (assuming their developer tools are updated to support long paths). It would be great to enable the feature more broadly in the future, but there is no timeframe for when that might happen. It's a classic chicken-and-egg problem. |
Beta Was this translation helpful? Give feedback.
-
As a first step, would you accept a PR that adds a commented out line to the app.manifest template? <!-- This can be used to inform the system that the app is compatible with long file paths.
More info: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation -->
<!--<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>--> |
Beta Was this translation helpful? Give feedback.
-
What are things that can be done to improve the the file new experience in Visual Studio to provide a richer and simplier experience. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
Make Developing and Developers life less painful on win32 subsystem.
reunion 1.0 is yet to hit us. force using Long path awareness for all apps that use reunion components.
can't stuck in 1995 anymore. though maintaining backward compatibilty (is app 32 bit or targeting windows version X ? then stuck in 255 else underlying filesystem's limit. )
win32 subsystem also has to be forward compatible for future relevancy. it's high time the subsystem made full use of NT.
Beta Was this translation helpful? Give feedback.
All reactions