Lennart Poettering
Lennart Poettering
urks github made this a big confusing. i am asking for a comment add to the leading zero thing. i.e. where i asked earlier, since it's not obvious to me...
PR looks good to me as it is now. @yuwata it's in your hands now
so lemme get this straight there are basically three cases: 1. private key from file, we already support that with --private-key= 2. private key from openssl 1 "engine". For this...
> The question is rather, why? No other tool uses such a scheme (including our own, in already released versions, which need to keep working as-is), so it would be...
lgtm, just some naming tweaks please
yeah, this doesn't look right. The whole point of fd_reopen() is to pick new flags for opening the inode pinned by an existing fd. If you start inhereting flags the...
O_APPEND is such a weird interface... So I am very sure fd_reopen() should not be modified like this. We use it for a variety of cases, and copying over O_APPEND...
So i am pretty sure we should copy over file offsets, not modes, see above for an explanation why.
still think we should primarily focus on the offsets. besides the fact that O_APPEND is a bit weird, it's an output only thing, doesn't solve the offset issue for input,...
As mentioned, I am fine if you propagate O_APPEND if set, see my proposal above. But please make this specific to O_APPEND, nothing else. And please explicitly propagate the file...