I found this one while testing the new nap() code on FAT
(as a non-root user).
WDYT?
Have a nice day,
Berny
>From d76591d41230f06a7002336c3f4111de5ab2f27b Mon Sep 17 00:00:00 2001
From: Bernhard Voelker
Date: Wed, 22 May 2013 00:53:50 +0200
Subject: [PATCH] test-lchown, test-chown: also skip t
On 05/21/2013 04:10 PM, Eric Blake wrote:
Thanks for the review.
> On 05/21/2013 07:27 AM, Bernhard Voelker wrote:
>> +
>> +static void
>> +clear_temp_file (void)
>> {
>
> Needs a close here to work...
>
>> + unlink (TEMPFILE);
>> }
Argh, yes, that just postponed the unlink problem to proce
On Wed, Apr 24, 2013 at 01:18:52PM +0100, Pádraig Brady wrote:
> On 04/23/2013 11:16 AM, Dmitry V. Levin wrote:
> > On Tue, Apr 23, 2013 at 10:54:03AM +0100, Pádraig Brady wrote:
> >> I'm still thinking the gnulib patch should be applied though,
> >
> > Since the regression in glibc was detected b
On 05/21/2013 03:08 PM, Eric Blake wrote:
> On 05/21/2013 06:52 AM, Bernhard Voelker wrote:
>> + if (-1 == fd)
>> +{
>> + ASSERT ((fd = creat (BASE "naptmp", 0600)) != -1); /* Never closed.
>> */
>> + ASSERT (unlink (BASE "naptmp") == 0);
>
> unlink() of an open fd is not guarante
On 05/21/2013 07:27 AM, Bernhard Voelker wrote:
> On 05/21/2013 03:08 PM, Eric Blake wrote:
>> On 05/21/2013 06:52 AM, Bernhard Voelker wrote:
>>> + if (-1 == fd)
>>> +{
>>> + ASSERT ((fd = creat (BASE "naptmp", 0600)) != -1); /* Never closed.
>>> */
>>> + ASSERT (unlink (BASE "nap
On 05/21/2013 01:52 PM, Bernhard Voelker wrote:
>> 05/03/2013 10:37 AM, Bernhard Voelker wrote:
>> I.e., the numbers did not went significantly down for that non-VM system. ;-/
>
> Playing with the code a bit and testing on various VMs (where the race
> showed up most probably), it turned out that
On 05/21/2013 06:52 AM, Bernhard Voelker wrote:
>> 05/03/2013 10:37 AM, Bernhard Voelker wrote:
>> I.e., the numbers did not went significantly down for that non-VM system. ;-/
>
> Playing with the code a bit and testing on various VMs (where the race
> showed up most probably), it turned out that
> 05/03/2013 10:37 AM, Bernhard Voelker wrote:
> I.e., the numbers did not went significantly down for that non-VM system. ;-/
Playing with the code a bit and testing on various VMs (where the race
showed up most probably), it turned out that the multiplier for the nap()
delay is not sufficient.
