[CMake] Problem with archive_write_finish_entry(): Can't update time...

[Daniel Pfeifer]

 Am Donnerstag, den 27.01.2011, 12:48 +0100 schrieb David Cole 
 <david.cole at kitware.com>:
> On Thu, Jan 27, 2011 at 12:45 PM, Daniel Pfeifer
> <daniel at pfeifer-mail.de> wrote:
>>
>> Am Donnerstag, den 27.01.2011, 11:42 +0100 schrieb David Cole
>> <david.cole at kitware.com>:
>>>
>>> Are the time stamps actually restored on extract (when extracting 
>>> with
>>> CMake and ignoring the warning output)? Or do all files have "time 
>>> of
>>> extraction" as their modified times?
>>
>> No, the time stamps are not restored: All files have the current 
>> time as
>> their last modified time.
>> When extracting the same file with 7-Zip, the timestamps are 
>> correctly
>> restored.
>>
>> CMake successfully restores the timestamps when extracting .zip 
>> files, but
>> fails with .tar.bz2 and .tar.gz archives.
>>
>>> On Thu, Jan 27, 2011 at 11:37 AM, Daniel Pfeifer
>>> <daniel at pfeifer-mail.de> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> Am Mittwoch, den 26.01.2011, 08:14 -0500 schrieb David Cole:
>>>>>
>>>>> >From the libarchive source code, it looks like this message 
>>>>> appears as
>>>>> a "warning" and returns ARCHIVE_WARN.
>>>>>
>>>>> CMake spits out an error message whenever a libarchive function
>>>>> returns anything other than ARCHIVE_OK.
>>>>>
>>>>> Perhaps we should detect ARCHIVE_WARN and only emit a "CMake 
>>>>> Warning"
>>>>> message rather than a "CMake Error".
>>>>
>>>> Yes, that would be better.
>>>>
>>>>> As to what could be causing it in the first place... perhaps 
>>>>> there's a
>>>>> permissions problem of some sort? Do you have full write 
>>>>> permissions
>>>>> in the directory where you are extracting? Do the files actually
>>>>> appear afterwards even though you're seeing these messages? Is it 
>>>>> a
>>>>> "deep" path (long name)?
>>>>
>>>> I am working with an administrator account on Windows, so I don't 
>>>> think
>>>> that permissions cause the problem. The paths are quite shallow 
>>>> (direct
>>>> subdirectory of 'C:\').
>>>> The files get extracted just fine. Maybe this warning can be 
>>>> safely
>>>> ignored. It is just annoying that it produces so much output.
>>>>
>>>>> If you untar the same archive.tgz file with another tar tool, do 
>>>>> you
>>>>> get any warnings or errors from it?
>>>>
>>>> Works without any warnings. But maybe the warnings are just not
>>>> displayed...
>>>>
>>>> cheers, Daniel
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at:
>>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.cmake.org/mailman/listinfo/cmake
>>>>
>>
>>
>
> So that's a real problem for people who require time-stamp
> restoration.... I think we should leave the CMake output as an error
> then.
>
> We've not had any reports of this from anyone else, though, so the
> question is still: what causes this in your case?
>
> Can you send us a *.tar.gz file that demonstrates this problem?

 I can reproduce the problem with the following CMake code:

 cmake_minimum_required(VERSION 2.8)
 set(url 
 http://sourceforge.net/projects/docbook/files/docbook-xsl/1.75.2/docbook-xsl-1.75.2.tar.bz2/download)
 set(archive ${CURRENT_BINARY_DIR}/archive.tar.bz2)
 file(DOWNLOAD ${url} ${archive} EXPECTED_MD5 
 0c76a58a8e6cb5ab49f819e79917308f)
 execute_process(COMMAND ${CMAKE_COMMAND} -E tar xfz ${archive})

> Where did the tar.gz file come from?

 When I download the file with my browser and call the cmake -E in a 
 terminal I get the same errors.

> p.s. -- and if it's ok with you, let's keep this discussion on the
> CMake list for archiving and later-google-searching... (I'll wait for
> your next reply before putting this one up on the list...)

 Absolutely! I did not send my last message off-list on purpose; I just 
 forgot to double check the reply-address.
 A propos: Why is the reply address of the cmake mailing list not 
 cmake at cmake.org per default?

 cheers, Daniel