(I'm not subscribed to dev@perl...) On Mon, Apr 20, 2009 at 6:18 PM, Marc Adkins 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;