On Fri, Feb 8, 2013 at 6:42 AM, Uros Bizjak <ubiz...@gmail.com> wrote:
> On Fri, Feb 8, 2013 at 3:07 AM, Ian Lance Taylor <i...@google.com> wrote:
>> On Thu, Feb 7, 2013 at 2:43 PM, Uros Bizjak <ubiz...@gmail.com> wrote:
>>>
>>> I did hit one new error that seems related:
>>>
>>> --- FAIL: TestChtimes (0.00 seconds)
>>> os_test.go:681: AccessTime didn't go backwards;
>>> was={63495872497 0 47130825733376}, after={63495872497 0
>>> 47130825733376}
>>> os_test.go:685: ModTime didn't go backwards; was={63495872497
>>> 0 47130825733376}, after={63495872497 0 47130825733376}
>>> FAIL
>>> FAIL: os
>>
>> Something has gone wrong in the file
>> libgo/go/syscall/libcall_linux_utimesnano.go. The function in that
>> file will try utimensat. On your system that should return ENOSYS.
>> In that case the function should convert the times and call utimes.
>> The code looks OK to me but there may be something wrong with it. It
>> looks like the file times didn't change at all.
>
> From the strace -f, it looks that utimes is not called at all in
> between two relevant stats:
Strange. What I would expect to happen is that the function in
libcall_linux_utimesnano.go will call utimensat. Since your system
does not have that function, that will call the stub routine in
libgo/runtime/go-nosys.c, which will return -1 with errno set to
ENOSYS. The code in libcall_linux_utimensnano.go will see the ENOSYS
error and continue on to call utime. Clearly something is going wrong
in that sequence, but I don't know what.
Ian
