(I'm not subscribed to dev@perl...)

On Mon, Apr 20, 2009 at 6:18 PM, Marc Adkins <madkins@marchex.com> wrote:
I found this in mod_perl but the issue can be demonstrated without Perl.

Attempting to open a file for append using the following flags:

APR_BUFFERED | APR_BINARY | APR_CREATE | APR_APPEND

will not work.  The apr_file_open() function returns APR_EACCES.  If the following flags are used:

APR_BUFFERED | APR_BINARY | APR_CREATE | APR_WRITE | APR_APPEND

it works fine.  In a vacuum this behavior is debatable.  On the one hand, APR_APPEND could be seen to imply APR_WRITE.  On the other hand, it might be argued that the first case is incomplete flag-wise.

In the context of Perl, however, particularly when using the APR PerlIO filter, this becomes problematic.  Perl uses special character sequences which are converted to the proper flags down underneath the covers.  So in Perl '>' (write to a new file) converts properly but '>>' (append to an existing file or create a new one if necessary) does not.  There is no message either, AFAIK, it just fails silently.

The Perl code that builds the apr_file_open() flags needs to turn on APR_WRITE.

I think that this patch to mod_perl is what you need:

--- modperl_apr_perlio.c.orig    2007-12-31 02:39:50.000000000 -0500
+++ modperl_apr_perlio.c    2009-04-20 19:37:25.954107404 -0400
@@ -85,7 +85,7 @@
 
     switch (*mode) {
       case 'a':
-        apr_flag = APR_APPEND | APR_CREATE;
+        apr_flag = APR_WRITE | APR_CREATE | APR_APPEND;
         break;
       case 'w':
         apr_flag = APR_WRITE | APR_CREATE | APR_TRUNCATE;