This blog post is part of a series of posts on the web deploy providers.
This is what MSDN says about the filePath provider:
The filePath provider synchronizes individual files.
You can use the provider as a source or a destination argument depending if you want to sync to or from a file.
If you use the provider both as source and destination the file names doesn’t have to match (i.e. you can change it).
If the name of the destination file differs from that of the source, the name of the destination file will remain the same, but the contents of the file will be updated to those of the source.
- The filePath provider takes an argument that is the full path of a single file (e.g., C:\msdeploy\destinationfolder\file2.txt).
- UNC paths and mapped network drives are supported.
- Environment variables like %windir% are supported, but wildcard characters are not.
- If the path contains spaces, the path must be enclosed in double quotation marks.
The filePath provider takes an argument that’s one of the following:
- a file path
- alternatively an UNC path
Special Settings or Considerations
- You cannot use the archiveDir provider for the destination argument when the filePath provider is the source argument (use the package provider if so).
- By default, the provider doesn’t synchronize ACLs, attributes, or ownership information. This is because the permissions are copied as security identifiers (SIDs) and may not work uniformly on all computers.
If you need to synchronize both permissions and content, you can use the optional includeAcls provider setting to include ACLs in the sync operation.
note: ACLs will be copied as SIDs. For the permissions to be set correctly, you must use domain accounts or have local accounts with matching SIDs on both the source and destination computers.
I was thinking about what examples I could think of to show off the filePath provider and basically the filePath provider isn’t really used that much on its own. It’s often used as a “low-level” implementation for the contentPath or dirPath providers (and such).
However, one example came to mind.
Let’s imagine the following scenario:
A build server executes a deployment configuration that uses an external web service to feed data into our system.
We want to have control over that data and the way we do that is to send an xml file containing the input for the service.
We own the xml file and we have convinced the owners of the web service to let us upload the xml file to their server (via a network share).
They trigger the service to read new data whenever the file changes as long as the file is named according to their standards.
The image above is meant to illustrate what we’re trying to accomplish which is:
- sync file input.xml to remote/off-site network share \\VIRJOLE-WFE1\in
- rename the file on destination from input.xml to svc-input.xml (just to show off that functionality)
On line 4 you can see that I’m changing the file name on destination (according to the “specification”).
Error: An error was encountered when processing operation ‘Create File’ on ‘\\VIRJOLE-WFE1\in\svc-input.xml’.
Error: The error code was 0x8007052E.
Error: The user name or password is incorrect.
Executing that command however will result in an error (as above).
The problem is that the network share resides in a remote domain, hence we need to authenticate with “their” domain to be able to create files at the network share.
I’m using the Windows Credential Manager to add an account that will be used “going over the wire” to server “VIRJOLE-WFE1”.
And, the result…