Бинарная разница в файле Zip / Jar

Question

Кажется, что создание jar или zip из одинаковых исходных файлов всегда приводит к другому файлу. Я попробовал это как с помощью команды java jar, так и задач jar и zip в ant.

Похоже, что из-за того, что для новых банок / почтовых индексов установлена ​​временная метка для текущего сохраненного файла.

Есть ли способ заставить zip-инструмент просто использовать временную метку файла в файловой системе, чтобы гарантировать, что jar-файл, созданный из того же источника, будет выглядеть точно так же?

Answer 1

Разница в двоичном коде связана с отметкой времени файлов манифеста. Если вы позволите jar создать манифест сам, он создаст манифест на и установите созданный манифест в currentTimeMillis.

Вы можете решить это:
1. Не добавляйте манифест (если вы используете ant, вы должны использовать zip вместо jar)
2. Добавьте манифест, как вы добавляете обычные файлы. (Таким образом, манифест - это файл в вашей файловой системе, и он не создается на лету)

Answer 2

Используя стандартную библиотечную утилиту java.util.zip.ZipOutputStream, можно создавать zip-файлы с воспроизводимым содержимым.

Единственная хитрость в том, что отметка времени записей zip должна быть исправлена ​​с помощью этой хитрости:

ZipOutputStream zos=...;
ZipEntry ze=new ZipEntry("Filename");
zipEntry.setTime(0);
zos.putNextEntry(ze);
try
{
   zos.write(data);
}finally
{
  zos.closeEntry();
}

Answer 3

У меня была похожая проблема, и, как подсказывает pjz, я решил ее, «прикоснувшись» к файлам перед добавлением их в банку (так что это сработало для меня :-)). Вы можете найти сенсорный экран для Windows, если вам это нужно, в GNU Windows Utilities, основные утилиты: http://gnuwin32.sourceforge.net/packages/coreutils.htm, но это большой пакет только для этой единственной (хотя есть много других полезных утилит, которые вы можете как) или, альтернативно, загрузите что-то вроде http://www.softpedia.com/progClean/Touch-for-Windows-Clean-41086.html.

Answer 4

Хорошо, мы с коллегой придумали решение, которое работает для нас.

Вместо того, чтобы перестраивать весь процесс сборки, чтобы не удалять файлы классов или jar, мы используем следующую процедуру:

1. Создание новых артефактов.
2. Используйте jardiff (часть jnlp ) для сравнения изменений из предыдущей сборки.
3. Если созданный jardiff diff не имеет изменений, получите артефакт из предыдущей сборки.

Да, я знаю, это звучит глупо, но это наверняка лучше, чем переписывать скрипт сборки, чтобы принять это во внимание. Кроме того, мы можем сделать полностью чистую сборку на новой машине (в случае сбоя сервера), и этот процесс обеспечит создание только фактически обновленных jar-файлов.

Answer 5

Я не думаю, что есть способ заставить zip сделать это, но вы наверняка могли бы забить временные метки файлов в файловой системе до известной даты (используя команду «touch» в unix - я не знаю, что в Windows) прежде чем создать банку.