[Bug] [UWP] App crashes when picking more than 1,000 files

[DanielGilbert]

Description

When picking more than 1000 files on UWP at once using PickMultipleAsync() or when picking 1000 different files in a row with PickAsync(), the application will crash with a System.Exception, stating that:

The maximum number of items in the access list has been reached. An item must be removed before another item is added.

This is because the platform specific implementation for UWP is adding every file to StorageApplicationPermissions.FutureAccessList, which has a maximum storage capacity of 1000 files. This list is kept between app restarts and presumably also updates, and should only be managed by the app itself.

The issue surfaced for us after many months of usage, were a single file was added on a day-by-day base.

Steps to Reproduce

1. Call PickMultipleAsync for UWP
2. Pick more than 1000 files (or less, depending on how many have been picked before)
3. Click "Open" in the file dialog.

-- or --

Checkout the attached archive, which has a sample UWP app and 1001 random files. Simply click on PickFiles and select all files from the Sample Data folder. Then press "Open" and wait for the app to crash.

Expected Behavior

The app should continue to work as expected.

Actual Behavior

The app takes a long time to load all files and will finally crash with a System.Exception, after the maximum amount of items has been reached.

Basic Information

• Version with issue: 1.3.1+, after the FilePicker got added
• Last known good version: None
• IDE: Visual Studio 2022
• Platform Target Frameworks:
  • UWP: 10.0.17763

Reproduction Link

FilePickerUwpTest.zip

[DanielGilbert]

In case you need help implementing a fix on this item (PR or anything), I'm happy to sign a CLA and contribute. :)

[jfversluis]

@DanielGilbert your best shot at getting this fixed is probably if you indeed contribute. So if you're willing and able, you might want to give that a shot. Thanks!

[DanielGilbert]

@DanielGilbert your best shot at getting this fixed is probably if you indeed contribute. So if you're willing and able, you might want to give that a shot. Thanks!

Will do! Didn't want to start with a PR without asking beforehand. :)

[MitchBomcanhao]

if you simply remove adding the file to the future access list, you might be causing other stuff to break (this line of code wouldn't be there for no reason, and in the past we've had to use it on our own windows file picker because it'd not work correctly without it - eg it'll possibly fail as the app will not have permission to access the files you just picked.

I'm not sure how i'd handle the "pick over 1000 files" scenario, for a smaller number I'd just clear the older files in the future access list - they're likely to be old enough to have been handled by previous picking actions and therefore will no longer need to be in this list. I'd also consider clearing this list on application launch.

to be clear - my use case is:

• user picks a file (we don't do multiple files at the moment)
• the file pick result is returned, and we go get the file on the result object - we need access to the file there.
• once we've copied the file to our internal location, we no longer need access to it, and the file can be removed from the future access list.

[MitchBomcanhao]

what we potentially need is a way to copy the files into the app's storage as part of the file picker code, which would allow the file picker to be self contained and then we could immediately remove the files from the future access list.

eg

• you pick one or more files
• the file(s) get copied to a specific location in some folder inside the app's storage
  • this location is supplied as a parameter to the picker method (that'd be very useful), or:
  • this location is a temp folder that gets cleared off on app startup, and files are returned into a uniquely named folder which is returned with the results.
• the file(s) get removed from the future access list
• the result object from the file picker includes the locations from that in-app storage.
• the app can now decide what to do with those files.

if the user picks more than 1000 files, we can potentially do this processing in chunks, to guarantee that you'll never go over the 1000 files limit?

[DanielGilbert]

Hadn't had time to create the PR yet, sorry.

what we potentially need is a way to copy the files into the app's storage as part of the file picker code, which would allow the file picker to be self contained and then we could immediately remove the files from the future access list.

I'm a strong opponent on this one. The filepicker implementation already returns the StorageFile object. As long as you do not dispose this object, you can access the underlying file, and copy it everywhere you like.

I highly recommend re-reading the linked documentation at the beginning of my post. You should store this token, and use GetFileAsync or GetFolderAsync after you've disposed the StorageFile instance, so that you can get access again. You won't automatically get access to this file in this path, just because it's in this list. :) The Add function that is called in the linked code has a return value which is discarded by this implementation. The return value is the token you need to get access again to this file.

The most important part is, that the app should handle this list exclusively, so it can be cleaned up by the app. In our app, we are explicitly clearing the list at the moment right after the file gets added as a work around. If we would use this list for our app, it would be a real pain to filter.

[MitchBomcanhao]

ok, will do