Move file_chmod_directory and file_chmod_file out of config and into settings so that drush_chmod() is independant of the config system

I think the removal of upgrade tests will help.

1. +++ b/core/includes/file.inc
   @@ -42,6 +42,17 @@
   +const CHMOD_DEFAULT_DIRECTORY = '0775';
   ...
   +const CHMOD_DEFAULT_FILE = '0664';
   

   1. Can we define the constant values are octals instead of strings?

   2. I think the constant names should be prefixed with "FILE_". And because they're constants, I'm not sure whether the "DEFAULT_" in their names is required? How about these:

   FILE_CHMOD_DIRECTORY
   FILE_CHMOD_FILE

   3. Do we actually know why we're diverging from the PHP defaults? (at least mkdir() defaults to 0777)

2. +++ b/sites/default/default.settings.php
   @@ -450,6 +450,14 @@
   + * Value should be a string in PHP Octal Notation.
   

   Given that the values are moved entirely out of the config system and are only ever set in PHP now, the entire string to octdec() conversion appears to be obsolete?

   Consuming code either gets the setting from settings.php (PHP) or the constant value from file.inc (PHP).

   Thus, there are no more strings anywhere at all and we can use raw octals everywhere?

3. +++ b/sites/default/default.settings.php
   @@ -450,6 +450,14 @@
   +# $settings['file_chmod_directory'] = '0775';
   +# $settings['file_chmod_file'] = '0664';
   

   Given that we also plan to move the private/temporary filesystem paths into settings, I'm a bit concerned about the resulting DX in settings.php — we'll end up with this:

   $settings['file_chmod_directory'] = ...;
   $settings['file_chmod_file'] = ...;
   $settings['file_public_path'] = ...;
   ...
   

   I wonder whether we're able to plan ahead of time already?

   In an ideal world, I think I'd consider this:

   $settings['file_chmod_directory'] = ...;
   $settings['file_chmod_file'] = ...;
   $settings['stream']['public'] = ...;
   $settings['stream']['private'] = ...;
   $settings['stream']['temporary'] = ...;
   ...
   

   Hm. Actually, the proposed $settings keys here appear to be fine, since they're not related to stream wrappers - or much rather, they apply to all local filesystem stream wrappers.

   That said, to underline 1.2, a naming consistency between $settings['file_chmod_directory'] and the FILE_CHMOD_DIRECTORY constant would make most sense to me.

This looks ready to me, in case testbot comes back green.

Looks like a sensible and better approach than #2099467: Let non-interactive installers determine mode of files directory and its subdirectories - this is committable once major and critical week is over

Looks like Alex has got this.

Committed a3c8c88 and pushed to 8.x. Thanks!

I think we need a change notice to explain how it is different from Drupal 7.

Added Change Record.

@j4 the point of the change notice is to tell people how this was configured in Drupal 7

  $dir_mode = variable_get('file_chmod_directory', 0775);
  $file_mode = variable_get('file_chmod_file', 0664);

Is now...

  $dir_mode = settings()->get('file_chmod_directory', FILE_CHMOD_DIRECTORY);
  $file_mode = settings()->get('file_chmod_file', FILE_CHMOD_FILE);

in Drupal 8

Also the reason we are making this change is because the variable system is being replace by configuration stored in files and, therefore, we can not store this in configuration.

Have added this. Sorry this was my first time in trying to create change records..thank you for the explanation.

Jaya

I'm not 100% sure if this is related to my issue or not, as I haven't had tons of time to dig... but if I use Drush (latest master version from GitHub) and download drupal-8.x dev, then do a drush site-install, the install completes successfully, and drush status works perfectly, but Drupal keeps giving me the 'you probably need to rebuild' message.

I tracked it down to the settings.php file having 444 permissions—if I switched to 744, then loaded the page again, everything worked great. I went back to 444 after that, and things kept working. So it seems if I do a drush site-install, then pop over to the web browser, some final thing needs to be written to settings.php but can't be.

Until I updated those permissions, I got the rebuild message in the browser, and the following in Apache's error log:

PHP Fatal error:  Call to undefined function cache() in /var/www/drupal-8.x-dev/core/includes/module.inc on line 33

Maybe drush site-install is where the problem lies? I have no idea, but will investigate later if I'm able.

@moshe - will do. For now, I've left comments everywhere someone else might find potential solutions, hopefully that helps others who get stuck in the same rut.

The change record here could use a bit of work. Before-and-after examples for D7 and D8 would be very helpful, and the text is not very clear.

This issue introduce a bug in file_unmanaged_copy() https://drupal.org/node/2191631

Sorry, it looks like the bug has been around for a while. I wrongly presumed it was this patch that caused the issue since it was so recent and the bug seemed like something that would have been caught fairly quick.