New Feature Proposal

Description

I think that it might be a good idea to move from Azure Pipelines to GitHub Actions in order to have everything in one location. While there's no other benefit, I think that not having to switch pages is always nice. And so far, the two services seem to have feature parity for everything that this project needs.

Discussion

If this is done, the following steps might also be a good idea:

• Rename master to release in order to match my other/future repositories.
• Before swapping, check if GitHub Actions supports testing/building UWP projects (i.e. whether it has the correct Windows SDK).

New Feature Proposal

Description

Most file systems support the concept of .NET's FileShare enumeration, meaning that an opened file can be accessed by 1:N other streams. Currently, Files defaults to the FileShare.None value in the implementations because UWP doesn't support FileShare. Nontheless, it would be awesome to have support for it, e.g. for lock files.

Discussion

The reason why it's not here yet is UWP which doesn't support FileShare. Of course, UWP should not be a blocker for important APIs. We could go the same route as with the FileAttributes and simply take the FileShare as a suggestion. This means that Files doesn't guarantee that the FileShare is used (and therefore doesn't, for example, add it to the specification tests). This could obviously be confusing from time to time, so who knows it it's a good idea.
As a supporting point for this behavior, FileShare.Inheritable is not supported by Win32, so there's similar behavior.

Bug Report

Environment / Version Details

Operating System (OS):

• Windows
  • Win32
  • UWP
• Linux
• macOS

.NET Runtime:

• .NET Framework
• .NET Core
• .NET
• Other (Please specify the details in the description)

Files Version:

• Newest Version
• Older Version (Please specify the details in the description)

Description

This is a follow-up issue for #11 (see Discussion).

The InMemoryFileSystem currently creates a copy of the current file content for each concurrent reader/writer. This means that readers will not "be notified" about changes made by a writer and that the last writer, if there are multiple, wins.

Expected behavior

The InMemoryFileSystem should maybe allow multiple actors to work on the same content.

Actual behavior

The InMemoryFileSystem creates a copy of the file's content for each actor.

Steps to Reproduce

None.

Discussion

It should be evaluated whether the current behavior is fine or not. I honestly don't really know how real file systems handle this scenario. It might even be a valid one. If so, no change might be necessary.

New Feature Proposal

Description

Files should provide support for watching the underlying file system.
It is never guaranteed that every file system has watch-support, meaning that such an API should be opt-in, i.e. it will not be guaranteed a watcher will always work/will always notify about every change. It's basically going to be "we're reporting whatever is possible, don't blindly trust what we're telling you about the changes".

System.IO already provides native support for this via the FileSystemWatcher and UWP apparently allows limited watching via search trickery. The in-memory file system can easily be extended with change notifications. Therefore, the three current implementations should all, to some extent, support such an API.

Discussion

I'm not sure about how exactly the API will look like. .NET's FileSystemWatcher might be a good inspiration though, but other approaches are, of course, also possible.

New Feature Proposal

Description

The StorageFile.CreateAsync method currently doesn't open a Stream. This is done on purpose to prevent situations where a Stream is not disposed. However, in certain situations, one wants to atomically create and open the file, e.g. for creating lock files. Files should therefore provide both options.

Discussion

The naming is open, but I'm leaning towards StorageFile.CreateAndOpenAsync(CreationCollisionOption, CancellationToken).

This change also makes sense together with #9, since #9 might add new parameters to the OpenAsync method. This parameter should then be mirrored.

The new method can also be implemented without introducing a breaking change by making it virtual instead of abstract. The default implementation in StorageFile could then call CreateAsync and OpenAsync in order. This is not atomic, but perhaps the best possible implementation for certain file systems.

Bug Report

Environment / Version Details

Operating System (OS):

• Windows
  • Win32
  • UWP
• Linux
• macOS

.NET Runtime:

• .NET Framework
• .NET Core
• .NET
• Other (Please specify the details in the description)

Files Version:

• Newest Version
• Older Version (Please specify the details in the description)

Description

This is a follow-up issue for #11 (see Discussion).

The InMemoryFileSystem doesn't support FileShare.Delete.

Expected behavior

The InMemoryFileSystem should support FileShare.Delete. Files should be deleteable when initially opened with this FileShare value.

Actual behavior

Currently deletion will simply fail because FileShare.Delete is not handled in any way.

Steps to Reproduce

None.

Discussion

None.

For version 1.0.0 at the latest, it would be awesome to have a logo for the package(s).
It doesn't have to be anything fancy, but it should be looking modern and remind viewers of file systems/files.

The icon will also be used for the repository (e.g. the README), so it should be scaleable.

Any ideas are welcome here.

Documentation Issue

Description

Files should have an automatically generated documentation page listing all public API members.
This should probably be done via DocFX. Ideally the documentation is auto-generated on successful builds/publishes.

Discussion

None.