On Mon, Jan 27, 2014 at 07:11:49PM +0100, Lennart Poettering wrote:
> On Mon, 27.01.14 19:09, Lennart Poettering (lenn...@poettering.net) wrote:
>
> > I just really don't like exposing two codepaths to the user. I want one
> > version that works for everybody, because people are highly like to
> >
On Mon, 2014-01-27 at 19:53 +0100, Kay Sievers wrote:
> >> >> Can we expect open(O_TMPFILE) to fail on kernels which do not support
> >> >> it?
> Yeah, but what happens for a "/tmp/does-not-exist" request? :)
#define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
the O_DIRECTORY part should make it fail
On Mon, Jan 27, 2014 at 07:53:51PM +0100, Kay Sievers wrote:
> On Mon, Jan 27, 2014 at 7:50 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Mon, Jan 27, 2014 at 07:15:23PM +0100, Kay Sievers wrote:
> >> On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek
> >> wrote:
> >> > On Mon, Jan 27
On Mon, Jan 27, 2014 at 7:50 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 27, 2014 at 07:15:23PM +0100, Kay Sievers wrote:
>> On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek
>> wrote:
>> > On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote:
>>
>> >> Can we expect ope
On Mon, Jan 27, 2014 at 07:15:23PM +0100, Kay Sievers wrote:
> On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote:
>
> >> Can we expect open(O_TMPFILE) to fail on kernels which do not support it?
>
> >> I guess th
On Mon, 27.01.14 19:09, Lennart Poettering (lenn...@poettering.net) wrote:
> I just really don't like exposing two codepaths to the user. I want one
> version that works for everybody, because people are highly like to
> misuse this otherwise. Logging is so basic that people shouldn't be able
> to
On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote:
>> Can we expect open(O_TMPFILE) to fail on kernels which do not support it?
>> I guess they will just silently ignore it? Then we never unlink?
> No, it is suppose
On Mon, 27.01.14 18:40, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote:
> > On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote:
>
On Mon, Jan 27, 2014 at 6:40 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote:
>> On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek
>> wrote:
>> > On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote:
>> >> Yupp, it's ce
On Mon, Jan 27, 2014 at 06:40:39PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote:
> > On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek
> > wrote:
> > > On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote:
> > >> Y
On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote:
> On Mon, Jan 27, 2014 at 5:37 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Mon, Jan 27, 2014 at 11:52:48AM -0200, Lucas De Marchi wrote:
> >> On Sun, Jan 26, 2014 at 3:21 AM, Zbigniew Jędrzejewski-Szmek
> >> > +int open_tmpfile(const
On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote:
> On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote:
> >> Yupp, it's certainly a good idea to make our logging functions safe for
> >> execution i
On Mon, Jan 27, 2014 at 5:37 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 27, 2014 at 11:52:48AM -0200, Lucas De Marchi wrote:
>> On Sun, Jan 26, 2014 at 3:21 AM, Zbigniew Jędrzejewski-Szmek
>> > +int open_tmpfile(const char *path, int flags) {
>> > +int fd;
>> > +char *p;
On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote:
>> Yupp, it's certainly a good idea to make our logging functions safe for
>> execution in any context.
>>
>> What I don't understands though is why mkostemp()
On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote:
> On Sun, 26.01.14 00:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > This will only work on Linux >= 3.11, and probably not on all
> > filesystems. Fallback code is provided.
> > ---
> > Hi,
> >
> > because on b
On Mon, Jan 27, 2014 at 11:52:48AM -0200, Lucas De Marchi wrote:
> On Sun, Jan 26, 2014 at 3:21 AM, Zbigniew Jędrzejewski-Szmek
> > +int open_tmpfile(const char *path, int flags) {
> > +int fd;
> > +char *p;
> > +
> > +#ifdef O_TMPFILE
> > +fd = open(path, flags | O_TMPFILE,
El 27/01/14 10:52, Lucas De Marchi escribió:
This unlink() doesn't make much sense with O_TMPFILE.
Yup, the name can't be seen in the filesystem and it goes away on
close() or program termination.
it is more like tmpfile(3) than mkstemp(3)
___
s
On Sun, 26.01.14 00:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> This will only work on Linux >= 3.11, and probably not on all
> filesystems. Fallback code is provided.
> ---
> Hi,
>
> because on bug https://bugzilla.gnome.org/show_bug.cgi?id=722889, I
> was looking into async sig
On Sun, Jan 26, 2014 at 3:21 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> This will only work on Linux >= 3.11, and probably not on all
> filesystems. Fallback code is provided.
> ---
> Hi,
>
> because on bug https://bugzilla.gnome.org/show_bug.cgi?id=722889, I
> was looking into async signal safety o
This will only work on Linux >= 3.11, and probably not on all
filesystems. Fallback code is provided.
---
Hi,
because on bug https://bugzilla.gnome.org/show_bug.cgi?id=722889, I
was looking into async signal safety of the journal logging functions.
All that do any formatting are unsafe, but sd_jou
20 matches
Mail list logo
