Allow SystemFile to work with paths that do not exist

[HEIC-to-JPEG-Dev]

Issue In its current form, SystemFile has limited use; specifically, it cannot be used for files that do not exist.

Reason The constructor forces the file to exist. The exists property is only valid at the time of the constructor, not nessesarily for when the developer needs to know.

Proposal Allow the constructor to work with path's that do not exist. The developer can then check "Exists" if they so required. An example of where this is useful; given a scenario where I'm creating a file (get the Systemfile first) or where I'm storing the path for later use.

Without this the developer has to have two different approches to file or path management. One for when the file exists, and one for when it does not.

[Arlodotexe]

In this storage abstraction, whoever creates the instance is responsible for making sure the resource exists before an instance of IFile or IFolder can be created.

Consumers (devs, tooling) assumes that once it has an instance, it can be used (call methods, read properties). Further, the more you pass around an instance in an undesirable state, the harder it is to debug issues with it.

Allowing IFile and IFolder to represent files that do not exist is a feature we aren't interested in adding right now. It would be too difficult to standardize and adjust existing code for.

[HEIC-to-JPEG-Dev]

I know this is closed, but... Isn't this an abstraction layer over a system that the developer doesn't have control over ? - if I look at the file system, the one thing I can be sure about is that I can't be sure about anything; the user can change the files, folders, rename them, delete, as can iCloud/OneDrive/GoogleDrive etc.

Just because something exists when you create the IFile, doesn't mean it exists from that moment forward.

The code must take this into account for all IO interactions, making this moot? "Allowing IFile and IFolder to represent files that do not exist is a feature we aren't interested in adding right now. It would be too difficult to standardize and adjust existing code for."

[Arlodotexe]

Yes, while the developer has some responsibility to ensure their code doesn't a delete a resource while it's also accessing it, resources can still disappear for other reasons, often outside the control of the running application.

That holds true for every API that you may use though -- that's what exception handling is for. The majority of the underlying libraries we've used to implement this (Windows.Storage, Microsoft.Graph, etc) already throw exceptions like FileNotFoundException, ArgumentException, etc. This is the pattern we adopted.