<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to 6: (Partial) Patch for zipnote 2.32 to change timestamps</title><link>https://sourceforge.net/p/infozip/patches/6/</link><description>Recent changes to 6: (Partial) Patch for zipnote 2.32 to change timestamps</description><atom:link href="https://sourceforge.net/p/infozip/patches/6/feed.rss" rel="self"/><language>en</language><lastBuildDate>Thu, 11 Sep 2008 07:32:48 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/infozip/patches/6/feed.rss" rel="self" type="application/rss+xml"/><item><title>(Partial) Patch for zipnote 2.32 to change timestamps</title><link>https://sourceforge.net/p/infozip/patches/6/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Back in late July, I made a patch which enables zipnote 2.32 to change timestamps of zip entries.  (Why?  Fedora's build process unpacks and repacks jars just to change their timestamps.  I'd like to change that.)  Instead of editing the comment attached to each entry within a zip, zipnote -t edits the timestamp.&lt;/p&gt;
&lt;p&gt;You use it like this:&lt;br /&gt;
&amp;gt; zipnote -t '2022-11-11 13:13:13' b.zip&lt;br /&gt;
&amp;gt; zipnote -t '2001-07-25' a.zip&lt;/p&gt;
&lt;p&gt;I realise now that zip 2.32 was succeeded by 3.0 in early July.  I think the &lt;a href="http://infozip.sourceforge.net/"&gt;http://infozip.sourceforge.net/&lt;/a&gt; homepage fooled me - even now, it still says zip 2.32 is the latest!&lt;/p&gt;
&lt;p&gt;The other problem is that there are many different possible (optional) timestamps inside zip files.  My patch changes the basic timestamp z-&amp;gt;tim, which I think is the original DOS timestamp from the earliest versions of the Zip format ("last mod file time"/"date" from appnote.iz).&lt;/p&gt;
&lt;p&gt;It looks as jar files created by Java's jar command use the DOS timestamp and nothing else, but most zip implementations, including Info-Zip, probably include whatever timestamps are native to the host system.&lt;/p&gt;
&lt;p&gt;Rather than try to handle every time-related optional field ever invented for Zip files (eg QDOS), a reasonable solution might be to remove any optional attributes which are known to contain timestamps.  Removing all unknown attributes might be safer, but it's probably a bit too extreme!&lt;/p&gt;
&lt;p&gt;I don't really know what I'm doing well enough to tackle that, but I thought I'd send in my patch in case it can be used.&lt;/p&gt;
&lt;p&gt;Sean.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Sean Flanigan</dc:creator><pubDate>Thu, 11 Sep 2008 07:32:48 -0000</pubDate><guid>https://sourceforge.net06a96dd0f152db59c3ba45e429d2271fee9f45dd</guid></item></channel></rss>