Site installs crash if files directory is not empty about blt

[grasmash]

That seems odd. What permissions are necessary to avoid this? I think we need to focus on permissions rather than owners.

[danepowell]

It's an issue of ownership, not permissions. You can only chmod files that you own. As far as I know, there's simply no way to reliably run chmod on the files directory unless you use sudo or the www-data user that owns the files.

[CashWilliams]

Well locally we could sticky bit permissions on the files directory during initial setup, thus it can be a permissions issue.

No clue if Windows supports something like that, thus this may be a *nix based fix.

[danepowell]

Sounds reasonable. I'm not very familiar with the sticky bit or if it allows you to chmod files you don't own. It sounds like we'd set the sticky bit on the files directory and this would essentially give the local user root access to that directory?

[CashWilliams]

I'm not saying it should be the resolution. The existing might still fail, or it will just not execute if the action would result in no change. Well, the sticky bit wouldn't be 'root' level access, more like create a shared/public folder which multiple users (www-data, local user etc) have the same write access.

[grasmash]

I'm making the chmod optional for the time being to circumvent this issue: #137

[danepowell]

Thanks. I've been testing this and I can't find any way around it (sticky bit doesn't help). Because of Drupal's file structure, I think there's simply no way to reliable chmod anything in the files directory. The logic is pretty simple:

• The web server will create files owned by itself in the files directory. There's no way to avoid this that I know of.
• You cannot chmod or chown files that you don't already own. You also can't remove them. If you want to fully manage a Drupal install, you basically are required to have sudo access.

[danepowell]

@grasmash that was actually not the problematic line. There's several instances of chmod in setup.xml, the one that causes problems is this one: https://github.com/acquia/blt/blob/8.x/template/build/core/phing/tasks/setup.xml#L90

I opened #151 to fix this. But I think this is only a stopgap (it still fills the screen/logs with tons of "failures").

@grasmash can we just make the chmod more selective so it excludes the files directory? I'm not sure what the original intent was

[gapple]

Another issue is that files should only receive 644 (no execute bit). I have files that are committed to git as 644, and re-running a site install unnecessarily marks them as changed due to the permission change to 755.

Not quite sure why this chmod is actually needed, other than maybe making sure the files are readable by the webserver even if the owner and group are different than the webserver user?

[grasmash]

Seems like multiple merged PRs have addressed this issue.

@danepowell sites/default needs to be writable in order to create local.settings.php and in order to modify settings.php (to add blt.settings.php require statement) when necessary.