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

David Cole david.cole at kitware.com
Fri Jan 28 13:37:55 EST 2011


I can't reproduce your issue here. (I had to modify your code because
CURRENT_BINARY_DIR was missing the CMAKE_ at its beginning. And since I
modified it anyhow, I added SHOW_PROGRESS and made min req'd be 2.8.3...)

Are you sure you're using 2.8.3 when you see the problem?

Can you repro this on another windows machine? (Mine is a Windows 7 x64, up
to date with updates, running VS 2010 and CMake 2.8.3 in a normal Windows
command prompt... Maybe there's something in your ENV that triggers
this...?)


Thanks,
David


Here's a transcript of what I did (and the results, void of errors or
warnings ... although it does show an interesting variation on the
notion of "progress" ...):
==============================================

C:\Users\davidcole\Dashboards\My Tests\b16>mkdir b3

C:\Users\davidcole\Dashboards\My Tests\b16>type CMakeLists.txt
cmake_minimum_required(VERSION 2.8.3)
set(url
http://sourceforge.net/projects/docbook/files/docbook-xsl/1.75.2/docbook-xsl-1.75.2.tar.bz2/download
)
set(archive ${CMAKE_CURRENT_BINARY_DIR}/archive.tar.bz2)
file(DOWNLOAD ${url} ${archive}
 SHOW_PROGRESS
 EXPECTED_MD5 0c76a58a8e6cb5ab49f819e79917308f)
execute_process(COMMAND ${CMAKE_COMMAND} -E tar xfz ${archive})

C:\Users\davidcole\Dashboards\My Tests\b16>cd b3

C:\Users\davidcole\Dashboards\My
Tests\b16\b3>"C:\Users\davidcole\Dashboards\Support\cmake-2.8.3\bin\cmake.exe"
--version
cmake version 2.8.3

C:\Users\davidcole\Dashboards\My
Tests\b16\b3>"C:\Users\davidcole\Dashboards\Support\cmake-2.8.3\bin\cmake.exe"
..
-- Building for: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 10
-- Check for working CXX compiler using: Visual Studio 10 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- [download 0% complete]
-- [download 100% complete]
-- [download 0% complete]
-- [download 100% complete]
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/davidcole/Dashboards/My
Tests/b16/b3

C:\Users\davidcole\Dashboards\My Tests\b16\b3>dir docbook-xsl-1.75.2
Volume in drive C is OS
Volume Serial Number is 9237-E092

Directory of C:\Users\davidcole\Dashboards\My
Tests\b16\b3\docbook-xsl-1.75.2

01/28/2011  01:31 PM    <DIR>          .
01/28/2011  01:31 PM    <DIR>          ..
07/24/2007  01:40 PM             2,305 .CatalogManager.properties.example
07/21/2009  12:40 PM             1,693 .cshrc.incl
07/21/2009  12:40 PM               217 .emacs.el
07/21/2009  12:40 PM             1,818 .profile.incl
07/21/2009  12:40 PM                54 .urilist
05/11/2008  05:27 PM               143 AUTHORS
07/24/2007  01:43 PM               578 BUGS
07/21/2009  12:40 PM               606 catalog.xml
01/28/2011  01:31 PM    <DIR>          common
05/22/2008  11:11 AM             1,960 COPYING
01/28/2011  01:31 PM    <DIR>          doc
07/21/2009  12:49 PM         2,236,416 DOCBOOK-BUILD.LOG
01/28/2011  01:31 PM    <DIR>          docsrc
01/28/2011  01:31 PM    <DIR>          eclipse
01/28/2011  01:31 PM    <DIR>          epub
01/28/2011  01:31 PM    <DIR>          extensions
01/28/2011  01:31 PM    <DIR>          fo
01/28/2011  01:31 PM    <DIR>          highlighting
01/28/2011  01:31 PM    <DIR>          html
01/28/2011  01:31 PM    <DIR>          htmlhelp
01/28/2011  01:31 PM    <DIR>          images
07/24/2007  01:43 PM             3,375 INSTALL
07/21/2009  12:40 PM            28,701 install.sh
01/28/2011  01:31 PM    <DIR>          javahelp
01/28/2011  01:31 PM    <DIR>          lib
07/13/2009  03:18 PM             3,795 Makefile
01/28/2011  01:31 PM    <DIR>          manpages
07/21/2009  12:49 PM             3,809 NEWS
07/21/2009  12:49 PM            11,475 NEWS.html
07/21/2009  12:48 PM             7,648 NEWS.xml
01/28/2011  01:31 PM    <DIR>          params
01/28/2011  01:31 PM    <DIR>          profiling
07/20/2009  08:12 PM             6,535 README
07/21/2009  12:49 PM           626,192 RELEASE-NOTES.html
07/21/2009  12:49 PM           290,510 RELEASE-NOTES.txt
07/21/2009  09:22 AM           487,507 RELEASE-NOTES.xml
01/28/2011  01:31 PM    <DIR>          roundtrip
01/28/2011  01:31 PM    <DIR>          slides
01/28/2011  01:31 PM    <DIR>          template
07/21/2009  12:40 PM                76 test.sh
01/28/2011  01:31 PM    <DIR>          tests
07/24/2007  01:43 PM               679 TODO
01/28/2011  01:31 PM    <DIR>          tools
07/21/2009  12:40 PM               175 uninstall.sh
07/21/2009  09:05 AM             4,504 VERSION
01/28/2011  01:31 PM    <DIR>          website
01/28/2011  01:31 PM    <DIR>          xhtml
01/28/2011  01:31 PM    <DIR>          xhtml-1_1
             24 File(s)      3,720,771 bytes
             26 Dir(s)      many, many bytes free


On Thu, Jan 27, 2011 at 2:34 PM, Daniel Pfeifer <daniel at pfeifer-mail.de>
wrote:
>
> 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
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110128/8a495118/attachment.htm>


More information about the CMake mailing list