coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new snapshot available: coreutils-8.24.161-1204d


From: Pádraig Brady
Subject: Re: new snapshot available: coreutils-8.24.161-1204d
Date: Mon, 18 Jan 2016 22:31:48 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 18/01/16 20:59, Assaf Gordon wrote:
> On 01/18/2016 03:38 PM, Assaf Gordon wrote:
>> On 01/18/2016 03:31 PM, Assaf Gordon wrote:
>>> On 01/18/2016 02:27 PM, Pádraig Brady wrote:
>>>> On 18/01/16 18:18, Assaf Gordon wrote:
>>>>>     FAIL: tests/cp/preserve-slink-time
>>>>
>>>> -2016-01-18 12:21:28.294123000 -0500
>>>> +2016-01-18 12:21:28.296528000 -0500
>>>>
>>>> cp -Pp didn't seem to preserve the timestamp on GPFS.
>>
>> This might be some weird bug in GPFS, not in CP.
>>
>> If I add a delay between the "ln -s" and "cp", then everything is fine.
>>
> 
> previous example was needlessly complicated.
> 
> Here's a more succinct example:
> ===
> $ for i in {1..5} ; do  \
>      ln -s nosuch$i d$i ; \
>      cp -Pp d$i d$i-without-sleep ; \
>      sleep 1 ;  \
>      cp -Pp d$i d$i-sleep ; \
>    done ; \
>    stat --format=%y,%n d*
> 
> 2016-01-18 15:54:03.362745000 -0500,d1
> 2016-01-18 15:54:03.362745000 -0500,d1-sleep
> 2016-01-18 15:54:03.364136000 -0500,d1-without-sleep
> 2016-01-18 15:54:04.368773000 -0500,d2
> 2016-01-18 15:54:04.368773000 -0500,d2-sleep
> 2016-01-18 15:54:04.370309000 -0500,d2-without-sleep
> 2016-01-18 15:54:05.374139000 -0500,d3
> 2016-01-18 15:54:05.374139000 -0500,d3-sleep
> 2016-01-18 15:54:05.375543000 -0500,d3-without-sleep
> 2016-01-18 15:54:06.379171000 -0500,d4
> 2016-01-18 15:54:06.379171000 -0500,d4-sleep
> 2016-01-18 15:54:06.381534000 -0500,d4-without-sleep
> 2016-01-18 15:54:07.384989000 -0500,d5
> 2016-01-18 15:54:07.384989000 -0500,d5-sleep
> 2016-01-18 15:54:07.386153000 -0500,d5-without-sleep
> ===
> 
> This is reproducible regardless of cp's version.

Seems like a cache coherency issue.
We can work around it with retry_delay_()
but it would be good to avoid.
Does a `sync d2` after the cp help?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]