On Mon, Apr 27, 2020 at 3:04 PM Joe Orton <[email protected]> wrote: > > On Mon, Apr 27, 2020 at 02:29:55PM +0200, Yann Ylavic wrote: > > The call chain is: > > apr_bucket_setaside(bucket, newpool) > > => file_bucket_setaside(bucket, newpool) > > => apr_file_setaside(&newfd, bucket->data->fd, newpool) > > => copy bucket->data->fd to newfd, move cleanup to newpool > > => bucket->data->fd->filedes = -1 > > => bucket->data->fd = newfd > > > > And since bucket->data is shared, all other buckets with the same data > > get their filedes set to -1. > > You mentioned this was a problem for split buckets, which I don't get. > For a split FILE bucket bucket->data is common across copies, so this > seems fine, the last "bucket->data->fd = newfd;" updates _all_ the split > buckets.
Ah yes indeed, you are obviously correct. I just extrapolated my issue (the file mangled by mod_proxy), and thought the same could happen with splitted file buckets.. Sorry for the noise and taking your time, and thank you/Rüdiger for your patience ;) > > That is clearly the implication of the apr_file_setaside() API warning > which extends to apr_bucket_setaside(). Alternatively you could say the > apr_file_setaside() implementation is broken and should work like > apr_mmap_dup(). Actually what I did for my proxy case is an apr_os_file_get() + apr_os_file_set() to create a file that mod_proxy can mangle at wish. The goal was also that sendfile() be finally used. > > (I think treating setaside as special for FILE is a bad road to start > down - I should be able copy and paste the FILE implementation as a new > MYFILE bucket type and have the core behave correctly, if not optimally) +1 Thanks, Yann.
