>> Thank you for your really specific answer, I will go to the IoT forum,
>> insider, etc to make the request.
>Don't bother. They won't change it. The inability to access these places is
>intentional. It means that programs can't read each-other's files so malware
>programs (e.g. spyware, ransomeware) don't work. This API is similar to what
>is available on mobile platforms (e.g. Android, iPhone) where it is extremely
>important that one program cannot interfere with another.
I disagree with the "Don't bother". Feedback is welcome, and actually can be
quite powerful to justify work. There are some technical challenges to let
CreateFile2 support removable storage, but less so than they used to be.
FYI I don't work on CreateFile2, though I've worked with the people who do :-)
>The question that interests me is why SQLite uses CreateFile2.
Because CreateFile is only available to desktop apps. Windows store (aka UWP
apps) can't use it - not if they want to be submitted to the Store. CreateFile
is quite diverse, many of its less common uses were problematic for Windows
store apps for technical reasons (esp re: AppContainer) or as noted the
reliability/trust/block-malicious-app expectations. CreateFile2 was invented as
the subset for safer UWP apps.
StorageFile is only an alternative if SQLite rewrites ALL i/o using it -
read/write is easy, but things like locking, memory mapped files and the like
less trivial file i/o behavior isn't available through StorageFile. There's a
reason CreateFile2 exists.
- Howard
