[path_provider_windows] add getExternalStoragePaths()

[squarebrakets]

This pr allows to get list of drives in a windows system using getExternalStorageDirectories();

List which issues are fixed by this PR. You must list at least one issue.
flutter/flutter#151059

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[stuartmorgan]

Thanks for the contribution!

Per comments below, it's not clear to me that the implementation here matches the expected behavior of this method.

[stuartmorgan]

This doesn't seem to correspond to the Android implementation, which is the de-facto standard for the behavior of the method (since it has previously been Android-only). From the Android docs:

Returns absolute paths to application-specific directories on all shared/external storage devices where the application can place persistent files it owns. These files are internal to the application, and not typically visible to the user as media.

This does not describe a top-level drive.

Shared storage devices returned here are considered a stable part of the device, including physical media slots under a protective cover. The returned paths do not include transient devices, such as USB flash drives connected to handheld devices.

This does not appear to be true of the implementation here.

[squarebrakets]

Returns absolute paths to application-specific directories on all shared/external storage devices where the application can place persistent files it owns. These files are internal to the application, and not typically visible to the user as media.

I assumed getExternalStorageDirectories() is to list storage drive roots to directly list users Storage. Last time I checked by default this function returns Phone and SD card roots. With proper permission this allows to list SD Card and Phone storage. According to.

packages/packages/path_provider/path_provider/lib/path_provider.dart

Lines 183 to 188 in d2705fb

	/// Paths to directories where application specific data can be stored
	/// externally.
	///
	/// These paths typically reside on external storage like separate partitions
	/// or SD cards. Phones may have multiple storage directories available.
	///

So to reflect that here getLogicalDrive is being used since default root directory is a C drive. Android only gives access to a folder that maybe similar to %USERPROFILE% directory. Difference is that windows does not have any restriction to all parts of the drive like android does.

USB flash drives connected to handheld devices.

User may opt to add custom partiion to their existing drive or may have multiple drives internally inside the machine or a SD card slot similarly to Phones' SIM/SD card slot.

[squarebrakets]

If the androids behavior I have seen is unexpected then getLogicalDrive has to be removed

[cbracken]

It would be useful to understand the underlying problem you're trying to solve with this PR. The idea of "external storage paths" as it exists on Android doesn't really map well to Windows.

If you wouldn't mind describing what you're trying to use this for, perhaps there's an alternate solution.

[squarebrakets]

It would be useful to understand the underlying problem you're trying to solve with this PR. The idea of "external storage paths" as it exists on Android doesn't really map well to Windows.

If you wouldn't mind describing what you're trying to use this for, perhaps there's an alternate solution.

I realize LogicalDrives deosn't really map to Androids storage media. So removing getLogicalDrives

[stuartmorgan]

It would be useful to understand the underlying problem you're trying to solve with this PR. The idea of "external storage paths" as it exists on Android doesn't really map well to Windows.
If you wouldn't mind describing what you're trying to use this for, perhaps there's an alternate solution.

I realize LogicalDrives deosn't really map to Androids storage media. So removing getLogicalDrives

The use case you provided in the associated issue is "Manage users drives from a flutter app"; that's the part of the PR you removed, so it's still not clear what the use case is here. Please provide (in the issue) the use case that is addressed by this PR, and an explanation of why getPath doesn't handle that case.

[squarebrakets]

It would be useful to understand the underlying problem you're trying to solve with this PR. The idea of "external storage paths" as it exists on Android doesn't really map well to Windows.
If you wouldn't mind describing what you're trying to use this for, perhaps there's an alternate solution.

I realize LogicalDrives deosn't really map to Androids storage media. So removing getLogicalDrives

The use case you provided in the associated issue is "Manage users drives from a flutter app"; that's the part of the PR you removed, so it's still not clear what the use case is here. Please provide (in the issue) the use case that is addressed by this PR, and an explanation of why getPath doesn't handle that case.

getPath would handle these cases. So closing this.