file_prepare_directory() / is_writable() on Linux don't support ACLs

In short

Drupal 7 incorrectly detects if a directory is writeable for httpd's user when permissions are granted via Linux native (extended) ACL.

The is_writable() PHP function, when working with local files successfuly detects writablity:

* is_writeable('sites/all/default/files/languages') returns TRUE

But when using stream wrappers (Drupal 7 way) check fails:

* is_writeable('public://languages') returns FALSE

Long story

I was unable to find an issue about this problem, but since I ran into troubles with writing/uploading files I can't sleep in the search of appropriate fix :(
Recently I started upgrading all my servers configuration to ACLs which I personally consider as the best way to do things.

In my setup write access to httpd's user on the 'sites/default/files' directory and subdirectories is granted via ACLs. For example, this is getfacl output for 'languages' directory:

# file: www/sites/default/files/languages
# owner: onkeltem
# group: onkeltem
user::rwx
user:www-data:rwx
user:onkeltem:rwx
group::rwx
mask::rwx
other::--x
default:user::rwx
default:user:www-data:rwx
default:user:onkeltem:rw-
default:group::rwx
default:mask::rwx
default:other::--x

As you see it is writeable for 'www-data' user. But when locale module tries to rebuild language js files I got error message:

The specified file temporary://fileZdBOPz could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.

and one more in the log:

File temporary://fileZdBOPz could not be copied, because the destination directory public://languages.

The problem

The file_prepare_directory() function checks if a directory is writable using PHP function is_writable():

  ...
  // The directory exists, so check to see if it is writable.
  $writable = is_writable($directory); 
  if (!$writable && ($options & FILE_MODIFY_PERMISSIONS)) { // (1)
    return drupal_chmod($directory);                        // (2)
  }

which in its turn calls stat() implementation of the stream DrupalPublicStreamWrapper which is DrupalLocalStreamWrapper which implements url_stat():

    ...
    if ($flags & STREAM_URL_STAT_QUIET || !file_exists($path)) {
      return @stat($path);
    }
    else {
      return stat($path);
    }

thus returning regular PHP stat array to the is_writable(), but since this array has nothing about extended ACLs all subsequent checks are senseless.

To finish the story lets see how things continue going wrong after is_writable() returns FALSE:

(1) Attempt to check - if we called with the option to modify permissions
(2) Try to chmod a directory...

Well, I'm not a guru and just interesting why we do this even? What are chances that having NO write access on a dir, we still have permissions to modify permissions? The only situation of I can think about and when this will work:

dr-xr-xr-x    www-data:www-data    mydir

.... and we already owning a dir. But after all, how happened that a dir got r/o - who and why would need this and under what circumstances? It was definitely not the Drupal who previously set r/o, then it should be an administrator who did this, right? Then why Drupal now making the directory writeable on its own? Maybe I'm missing somthing but yet I don't understand the reasoning of this action :)

Need help

Well, I don't know how this could be easily fixed, except of patching url_stat() to return modified stat array (with faked UID = httpd's UID, or with 777 mode), but IMHO the real solution would be:

* Don't check writability at all using any kind of PHP weird stuff - just try to _really_ _write_ a (test-) file.
* Don't chmod anything - this either won't work (when httpd is not owing a file) or would probably break some (of couse stupid) administrator's arrangements.

Also, to support ACLs Drupal shouldn't move files - just copy/unlink them (maybe it already does, I didn't check, but faced with this problem in Drush and thanks PHP devs - this is fixing in php.ini via to disable_function = rename.