You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2009/07/31 21:41:58 UTC
[compress] ar/cpio and last modfied times
Hi,
I've started to implement a commons-compress based antlib over in Ant
land
<https://svn.apache.org/repos/asf/ant/sandbox/antlibs/compress/trunk/>
and just realized we don't have a common getLastModified() method in
ArchiveEntry - maybe we should have.
What seems to be worse is that we don't really document what the
corresponding methods in ar and cpio entries will return - and we don't
have a single unit test that would set or read them,
To make things even worse, cpio claims it would be seconds since the
epoch but sets it with System.currentTimeMillis when unset
(CpioArchiveOutputStream#putArchiveEntry) which will be milliseconds
since the epoch - who is correct?
And finally (I was keeping the worst for the end) ArArchiveInputStream
won't set the time at all, even if it reads the corresponding bytes -
the writing code looks as if it assumed entry.getLastModified() to be a
in milliseconds since the epoch and wants to write seconds since the
epoch.
Can anybody more familiar with ar or cpio shed some light on what the
formats really expect?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] ar/cpio and last modfied times
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-08-01, Emmanuel Bourg <eb...@apache.org> wrote:
> Stefan Bodewig a écrit :
>> That's what I assume as well, I'm just hoping that anybody else would
>> know for sure before I "fix" it.
> I created an archive with GNU ar to check the timestamp, I confirm
> it's in seconds.
Thanks for the check (should have thought of that myself).
Then my last commits should be fine. I'll add a few testcases for
roundtrips (making sure we can read arcives correctly that we've
written) - and maybe for some natively created archives as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] ar/cpio and last modfied times
Posted by Emmanuel Bourg <eb...@apache.org>.
Stefan Bodewig a écrit :
> That's what I assume as well, I'm just hoping that anybody else would
> know for sure before I "fix" it.
I created an archive with GNU ar to check the timestamp, I confirm it's
in seconds.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] ar/cpio and last modfied times
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-07-31, Emmanuel Bourg <eb...@apache.org> wrote:
> Stefan Bodewig a écrit :
>> I've started to implement a commons-compress based antlib over in Ant
>> land
>> <https://svn.apache.org/repos/asf/ant/sandbox/antlibs/compress/trunk/>
> Nice! Do you plan to replace the archive/compress tasks in Ant with
> the new ones?
Not for Ant's core, but as a separate Ant library. This will allow the
tasks to be updated on a more frequent basis and they may take advantage
if commons-compress releases will be more frequent than Ant releases
(which is likely if only because of Ant's slow cycle).
And then there is this strong reluctance (which I share) of Ant
developers to introduce any external dependencies for core tasks.
>> To make things even worse, cpio claims it would be seconds since the
>> epoch but sets it with System.currentTimeMillis when unset
>> (CpioArchiveOutputStream#putArchiveEntry) which will be milliseconds
>> since the epoch - who is correct?
> http://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt
> CPIO time is in seconds.
That's what the comment in the code say as well, it just doesn't look
that way 8-)
>> Can anybody more familiar with ar or cpio shed some light on what the
>> formats really expect?
> I couldn't find a clear specification of the ar format
same here
> ... but I'm pretty sure the modification time is in seconds
> too.
That's what I assume as well, I'm just hoping that anybody else would
know for sure before I "fix" it.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] ar/cpio and last modfied times
Posted by Emmanuel Bourg <eb...@apache.org>.
Stefan Bodewig a écrit :
> I've started to implement a commons-compress based antlib over in Ant
> land
> <https://svn.apache.org/repos/asf/ant/sandbox/antlibs/compress/trunk/>
Nice! Do you plan to replace the archive/compress tasks in Ant with the
new ones?
> To make things even worse, cpio claims it would be seconds since the
> epoch but sets it with System.currentTimeMillis when unset
> (CpioArchiveOutputStream#putArchiveEntry) which will be milliseconds
> since the epoch - who is correct?
http://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt
CPIO time is in seconds.
> Can anybody more familiar with ar or cpio shed some light on what the
> formats really expect?
I couldn't find a clear specification of the ar format, and the original
code is not very readable [1], but I'm pretty sure the modification time
is in seconds too. Otherwise the date couldn't exceed 2001 (12 decimal
digits with milliseconds allows only 31 years from 1970).
Emmanuel Bourg
[1]
http://sourceware.org/cgi-bin/cvsweb.cgi/src/binutils/ar.c?rev=1.60&cvsroot=src
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org