search

sbt / sbt-assembly

Deploy über-JARs. Restart processes. (port of codahale/assembly-sbt)
MIT License
1.95k stars 224 forks source link

"[warn] Negative time" with sbt 1.4 #410

Closed Sciss closed 3 years ago

Sciss commented 3 years ago

steps

A reproducer would be https://github.com/Sciss/Mellite/releases/tag/v3.2.1 - if you clone the repository and check out tag v3.2.1, running sbt +mellite-app/clean +mellite-app/update +mellite-app/test mellite-app/assembly displays the warnings, at least on my computer.

problem

Since I use sbt 1.4.x, when running assembly, it fills my screen with

[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time
[warn] Negative time

(although technically it still seems to succeed)

eed3si9n commented 3 years ago

I wonder if this has something to do with GC monitor warning https://github.com/sbt/sbt/issues/6081. If so sbt 1.4.3 fixes it.

Sciss commented 3 years ago

I do run 1.4.3... Maybe it's the JDK (build 11.0.9+11-post-Debian-1deb10u1), or the OS (Debian stable).

Sciss commented 3 years ago

At least it's reproducible here; I'm tagging a new version, and will send a link soon.

Sciss commented 3 years ago

A reproducer would be https://github.com/Sciss/Mellite/releases/tag/v3.2.1 - if you clone the repository and check out tag v3.2.1, running sbt +mellite-app/clean +mellite-app/update +mellite-app/test mellite-app/assembly displays the warnings, at least on my computer.

eed3si9n commented 3 years ago

I guess another potentially sbt 1.4.x specific thing might be zero'ed out timestamp on the JAR file - https://github.com/sbt/sbt/pull/5344.

Sciss commented 3 years ago

Yes, sounds like it, googling for the 'negative time', it seems there are issues with last modified dates of files before a certain date.

bes1002t commented 3 years ago

Same issue here: about 170 rows with this warning for every compile process... very annoying If there is no change, and nothing has to be compiled, the issue does not occur.

I'm using sbt 1.4.6 and OpenJDK 11.0.9+11

bigpick commented 3 years ago

Adding on, also seeing the same issue; using 

sbt 1.4.6 (AdoptOpenJDK Java 11.0.8+10)

Changing to sbt version to 1.4.7 or 1.5.0-M2 did not have any effect either.

eed3si9n commented 3 years ago

I wonder if this is a downstream effect of including libraries built by sbt 1.4.x prior to the timestamp 2010-01-01 fix. If so maybe we should just filter the warning out somehow?

bes1002t commented 3 years ago

switching to sbt 1.4.8 does not change anything.

@eed3si9n filtering the warning out would be a quickfix I think. Best way is always to fix the source of the issue.

vreuter commented 3 years ago

+1 , also can report running into this on 1.4.8

polarker commented 3 years ago

+1, it even happened to me on 1.3.10.

Also, if I try jar xf alephium-0.7.2.jar of our latest release: https://github.com/alephium/alephium/releases/tag/v0.7.2 I got:

java.lang.IllegalArgumentException: Negative time
        at java.base/java.io.File.setLastModified(File.java:1441)
        at jdk.jartool/sun.tools.jar.Main.extractFile(Main.java:1472)
        at jdk.jartool/sun.tools.jar.Main.extract(Main.java:1364)
        at jdk.jartool/sun.tools.jar.Main.run(Main.java:409)
        at jdk.jartool/sun.tools.jar.Main.main(Main.java:1681)
polarker commented 3 years ago

but there is no such issue with our 0.7.0 release, and we did not upgrade sbt or sbt-assembly lately

kshakir commented 3 years ago

This is an example jar that is triggering the warning during sbt assembly: https://repo1.maven.org/maven2/org/typelevel/simulacrum_2.12/1.0.1/simulacrum_2.12-1.0.1.jar

This section of sbt-assembly[0] seems to try and preserve all values returned by ZipEntry.getTime(). But File.setLastModified() doesn't accept pre-1970 times and throws an exception[1].

Interestingly ZipEntry.setTime() seems like it doesn't accept times before 1980 or after ~2099[2], so I'm not sure what that implies about the validity of the times embedded in the above jar file. Also, ZipEntry.getTime() sometimes intentionally returns negative values as that API's version of None[3].

YuvalItzchakov commented 3 years ago

Reproduces with sbt 1.5.0.

eed3si9n commented 3 years ago

Looking at this now. Looks like @kshakir has done all the detective work. Thank you!

It seems like the key ingredient to reproduction is JDK 11.

Basically there are JAR files in the wild with 1970-01-01 timestamp since sbt 1.4.0 (https://github.com/sbt/sbt/pull/5344). Since sbt 1.4.8 this has been fixed to 2010-01-01 instead (https://github.com/sbt/sbt/pull/6290). I guess the fix would be to avoid negative time.

belowm commented 2 years ago

Wiping timestamp seems to break cache headers when creating a war. All static resources are now delivered with last-modified: Fri, 01 Jan 2010 00:00:00 GMT, preventing the browser from picking up a new version of the resource.

I think clamping the date to the time range that is supported by zip would be a better solution than setting it to a fixed value.

eed3si9n commented 2 years ago

See also packageTimestamp setting and the discussion in https://github.com/sbt/sbt/pull/6237

ThisBuild / packageTimestamp := Package.keepTimestamps

// or

ThisBuild / packageTimestamp := Package.gitCommitDateTimestamp