Make GetBasicPropertiesAsync and functions of StorageFile.Properties thread-safe and/or provide a lightweight way to clone a StorageFile
Currently StorageFile.GetBasicPropertiesAsync and functions on StorageFile.Properties will fail if other async operations are in progress on the file (except RetrievePropertiesAsync, which thankfully works Ok). This is very difficult to manage in a complex app where StorageFile objects may be passed around, perhaps between threads as well, although the problem occurs with just one UI thread as well.
It would be good if these functions did not fail if called simultaneously, but behaved as they would if you called them from two different StorageFile instances representing the same physical file.
This is made especially difficult by the fact that there is no way to clone a StorageFile instance which would be another solution to this problem, so maybe you should also consider that.
At the moment I am using RetrievePropertiesAsync as a partial workaround, although there is an annoying but with this whereby the file modified date and size as well I think are not updated after RetrievePropertiesAsync has fist been called on a StorageFile instance, so it would be good if you could fix this as well.
Currently these issues make it very difficult to work effectively with StorageFiles (and analogously StorageFolders) in complex apps.
Ben Stevens commented
Thanks for the reply. My app has various different panels as well and different windows. I might obtain a StorageFile from a picker, then it might be displayed in various places such as in a list of recent files, in a file info box, possibly in multiple different windows.
It is very difficult to engineer this so that I guarantee not to call GetBasicPropertiesAsync at the same time from one of the various components that uses the file. I see no reason why this function and the other get Properties functions cannot be called at the same time. This function and the other get properties functions do not modify the underlying file.
Also, even with operations that do modify the underlying file, it's still very difficult to synchronize these in the scenario I described. Is it not possible that requesting one of these operations could simply wait for the previous operation to finish? Maybe this could be added as an option, along with perhaps a timeout of how long to wait for.
At the very least, do you think you could ensure that calling RetrievePropertiesAsync for System.DateModified and System.Size retrieves the current values of these properties? (As I said, at the moment, after it has been called once on a StorageFile instance, subsequent calls will always return the same values for these properties.) This would allow me to workaround the issue of not being able to call GetBasicPropertiesAsync simultaneously as I can call RetrievePropertiesAsync simultaneously, plus it's quicker to use RetrievePropertiesAsync since there are other properties I am retrieving at the same time.
Thanks for listening.
Can you provide the scenario you're trying to solve here? The APIs are, generally speaking, thread safe already. HOWEVER, only one operation that may alter the identity of the item (Rename, move, etc…) is allowed at a time. This prevents undesired, unpredictable results.
Knowing what you're trying to solve for could help.