Am Donnerstag, den 27.01.2011, 12:48 +0100 schrieb David Cole
<[email protected]>:
On Thu, Jan 27, 2011 at 12:45 PM, Daniel Pfeifer
<[email protected]> wrote:
Am Donnerstag, den 27.01.2011, 11:42 +0100 schrieb David Cole
<[email protected]>:
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
<[email protected]> 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
[email protected] 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
