`File` resource as part of base package

[SteveL-MSFT]

Summary of the new feature / enhancement

Need a cross-platform file resource. Probably base it initially on the built-in file resource that is part of DSCv1.

Proposed technical implementation details (optional)

No response

[michaeltlombardi]

What properties are we expecting of the initial release of the File resource?

For reference and prior art, see:

• The Puppet file resource
• The Chef file resource
• The Ansible file module
• The Salt file.managed state

One thing to note is that while you could use a single resource to control file existence, contents, permissions, and link type for Windows and not-Windows, everything but existence and contents gets messy quickly when trying to represent things with a single resource.

Puppet handles this with providers and converting unix-isms to Windows, advising users to add a separate ACL resource to manage permissions more idiomatically for Windows if needed. Chef uses similar behavior, having users define the file resource and apply cumulative rights to it for Windows. Ansible has separate modules for Windows files and related resources (template files, copying, etc). While the salt state works on Windows, any unix file system specific options are ignored or not supported on Windows, and Salt has a separate win_file for managing permissions.

I would recommend either following the Puppet/Chef model (assume Unix, translate unix options to Windows in a standardized, documented way, and advise using a separate ACL resource for more control) or the Ansible model (one resource for unix files and another for Windows, fully separated idiosyncracies).

The benefit of the one file resource + Windows permissions is that you're always using a single resource type for files regardless of OS, though you may conditionally need to add ACLs for Windows (having a group depend on the OSInfo assertion). On the other hand, it's more complex to implement (not necessarily maintain, as the APIs for files aren't exactly high-churn for changes and features).

The benefit of two resources is primarily simplicity of implementation and declaration, though they can make manifests fork a bit when managing Windows/not-Windows simultaneously. On the other hand, for servers, I don't think that's as common an issue, as servers tend to be more focused in their configuration needs than client devices.

[SteveL-MSFT]

I think this is where @theJasonHelmick should author a spec to define the requirements and scenarios/use-cases.