Copy of static directory tries to update perms on `build/html`

[jhedstrom]

trafficstars

The current configuration for the copy:static task attempts to update perms on the build/html directory itself to match those of src/static.

Normally this isn't an issue, but when deploying on systems that have file perms setup in a manner that might not let the current user update file perms on that directory (if they are a group member for instance, but not the owner) the following warning is issued:

Warning: EPERM, operation not permitted 'build/html' Use --force to continue.

A current workaround is to alter tasks/copy.js to remove the mode: true option (introduced in #211, and a good thing in most cases).

[jhedstrom]

This came up again in the copy:defaults task (which copies files back from the build into src/sites/defaults), and the workaround was again to set mode: false on that command.

[grayside]

Possibly related, I am unsure why we have copy:defaults alongside the symlink:sites task of our scaffold operation.

If I read this right, the build process is copying the default settings into place, but this is blown away or conflicted shortly thereafter by symlinking the sites/default directory.

[arithmetric]

@grayside copy:defaults is meant to copy default* files (default.settings.php) from the build output (build/html/sites/default/default*) to the sites default directory under src. This is to facilitate keeping the example settings file before the default directory is replaced by the symlink task.

[mpgeek]

I'm running into this issue with a user who cannot change perms on the target directory. However setting mode: false didn't help, which made me think i have system config issues on that user. To get back up and running, i removed the copy:defaults task contents (still registers the task but it doesn't try to do anything). This allowed the user in question to perform a full build without errors.

It's interesting that the copy mode flag works fine for this user in this environment for copy.static and copy.tempbuild but not copy.defaults. We don't need to put back the default settings file in our scenario, so this will be ok for the short term. This seems really hacky though.