StorageLibraryChangeTracker support for network drives

[lukeblevins]

Proposal: Expand StorageLibraryChangeTracker to support network drives

Summary

Today, StorageLibraryChangeTracker can read changes for a variety of mediums abstracted by StorageFolder including user libraries, arbitrary folders on the local machine, secondary drives, and removable drives. Unfortunately, apps which want to track changes for a StorageFolder representing a network attached storage medium must rely on a queryResult.ContentsChanged event which lacks the rich notifications from StorageLibraryChangeTracker.

Rationale

• Developers are aware of the simplicity benefits from StorageFolder spanning different storage mediums, but find out the hard way that StorageFolder has unusual limitations for one of those mediums, network storage.
• More rich change notifications for filesystem changes would support app scenarios where developers need to monitor network drives (e.g. file managers, general utility apps) without having to refresh the entire collection

Scope

Capability	Priority
This proposal will allow developers to use StorageLibraryChangeTracker for reading modifications to network locations	Must
This proposal will allow Win32 developers to track network location changes with existing APIs	Could

Important Notes

No API proposal because this will leverage internal expansions to existing WinRT APIs. Related: https://github.com/microsoft/ProjectReunion/issues/8

Open Questions

How feasible would it be to coordinate work for removing (what seems like) a platform limitation?

[ghost]

someone should really really need to think of ways of removing MAX_PATH limitation from the win api. it's 2021 and that's also a platform limitation.

apparently lot of key reunion components also using MAX_PATH and no one talks about that

[JaiganeshKumaran]

@ecovio1 MAX_PATH limitations can be workaround by settings a Registry Key.

[ghost]

@Jaiganeshkumaran doesn't remove the limitation from the api itself. apps have to update their manifest and recompile just to access long paths which should have been removed from the api itself.

for example, explorer and almost all the programs I use still unable to access paths beyond 255 char. uwp apps/winrt/comv2 apis infact the whole win32 subsystem is subject to this. excusing backward compatibility just don't add up any more. especially when reunion promises to modernize apps and it's key components itself suffer from this.

[JaiganeshKumaran]

@ecovio1 The registry key was introduced in Windows 10 Anniversary Update and can be used with manifest change. If you want this feature, propose it with in a new issue.

[JaiganeshKumaran]

This proposal will allow Win32 developers to track network location changes with existing APIs

You mean with non-WinRT APIs?

[ghost]

If you want this feature, propose it with in a new issue.

that's microsoft's concern(still if they have any) about how they are gonna save this legacy subsystem.

situations should not have come down to this bad (ms's negligence towards windows) so that people outside of MS nowadays needs to remind/beg MS for the very basic limitations of their OS. smh

[JaiganeshKumaran]

But it will break old apps which assume 255 MAX PATH limit.